Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:

[Marsh Ray <[e-mail]>]

From: Bodo Moeller
> 
> While you are right, http://eprint.iacr.org/2000/025 alone
> isn't why MtE is broken (and https://twitter.com/marshray/status/401147046767239169/photo/1
> thus is a gross over-simplification -- not that there's anything
> wrong with that, per se ...).

Gross over-simplification tends to be what Twitter's best at.

AES-GCM good! RC4 bad! :-)

> That Bellare/Namprempre paper did show that MtE is not
> *generically* secure.  However, there's also
> http://eprint.iacr.org/2001/045 =
> http://www.iacr.org/archive/crypto2001/21390309.pdf , showing
> (sort of) that MtE *is* secure if E specifically is, for example,
> CBC encryption.  Well, we all know how well *that* went [*][**]
> ... but the various problems with CBC ciphersuites are not implied
> by the Bellare/Namprempre paper.

I feel the world of end users, admins, and other RPs shaking their
collective heads in wonder at these security proofs when they see
a giant flame-shooting robot at a party in Argentina:

http://www.youtube.com/watch?v=Mxm8JEUXOuQ

... then the presenter proceeds to decrypt traffic to a tier 1
ecommerce website ...

http://www.youtube.com/watch?v=4clpbJEWCzE

... and steal the login session cookie using attacks enabled
by CBC A-t-E mode.

All I can figure is that proving A-[at]-E CBC modes are
secure is cryptographers' equivalent of what (Down South where
I come from) we refer to as "Hey Y'all watch this!" E.g.,

http://www.youtube.com/results?search_query=hey+y%27all+watch+this

We have a long, sad, bibliography of *practical* attacks on A-[at]-E,
especially in conjunction with CBC modes. Bellovin, Rogaway, Wei
Dei, Vaudenay (many I missed) . IPsec, SSH, SSL, TLS .
all broken to various degrees. Too many operations where
attacker-supplied data interacts with must-be-kept-secret data.
Straightforward implementations result in side channels. Minor
info leaks turn into oracles. Oracles turn into practical attacks.

Has there ever been a serious attack on HMAC<hashfn> ?

Here's what I found for HMAC<MD4>

Practical Electromagnetic Template Attack on HMAC
by Pierre-alain Fouque, Gaëtan Leurent, Denis Réal, Frédéric Valette
(2007?)
> In this paper, we show a very efficient side channel attack against
> HMAC. Our attack assumes the presence of a side channel that
> reveals the Hamming distance of some registers
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.156.4969

But wait, HMAC<MD4> is worse. Again, *MD4*. IIRC TLS has only
ever supported HMAC<MD5> and later.

Full Key-Recovery Attacks on. HMAC/NMAC-MD4 and NMAC-MD5.
Pierre-Alain Fouque, Gaëtan Leurent, Phong Q. Nguyen.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.98.7316
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf

So if, say, TLS had supported HMAC<MD4> and the adversary had
the ability to make 2^88 record integrity queries, then with
2^95 time he could possibly (in 2007) insert a forged record
in that connection. But he'd better be careful, because if
he breaks it he'll have to start all over.

This technique seems unlikely to be of any use attacking the TLS PRF
"back through" the record MAC, because the PRF operates upon
completely new data with every handshake.

But it looks like SSLv2 used a bare hash rather than HMAC and even had
an option for MD2! Still, it would likely have been the 512 bit RSA certs
that were the weakest link.

Regards,

- Marsh

Unless stated otherwise, these are my own personal opinions.