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

[Robert Ransom <[e-mail]>]

On 11/14/13, Marsh Ray <[e-mail]> wrote:

> HMAC uses a double invocation of the full hash function each of which is
> initialized with a secret key. There's some pretty well respected proven
> properties on the security of HMAC.

Are these properties proved for all iterative hash functions, or only
for hash functions with the same general structure (block cipher in
feedforward mode) as MD5 and the pre-SHA-3 NSA hash functions?


> Additionally, the concern (D) is raised that an attacker who completely
> succeeds with (C) may then be able to "reach back through" several
> additional layers of HMAC in the TLS PRF in order to derive one or both of
> the cipher keys allowing full decryption of the protocol stream.
>
> To be clear, I say "reach back through" because I don't think there is
> actually a name for this attack model. Even if we were just talking about a
> hash function instead of HMAC, this is an attack capability *beyond* primary
> preimage. Primary preimage is "given h(M), find M' such that h(M') = h(M)",
> whereas this attack is: "given h(M), find M"!

I call that a “preimage recovery attack”.  I don't think that name is
standard, but it is an accurate description of the attack.


> The thing to worry about is block cipher modes' propensity to turn into
> plaintext oracles. This has been demonstrated as a practical attack on over
> and over again.

This is the most important point, and it's already being ignored (again).


> * Use encrypt-then-HMAC. Seriously. Yes really. No other choice is
> defensible in this age. If you think "oh but GCM" look more closely into its
> design.

There are plenty of other defensible choices for a MAC.

GCM has some bad design features, but its MAC is the good part (at
least for implementations with hardware support for multiplication in
GF(2)[X]).

Poly1305 (as used in draft-agl-chacha20-poly1305-03) is faster than
HMAC, and almost as secure.

SipHash is faster than Poly1305, and as secure as an HMAC truncated to
64 bits.  I don't expect it to be used in TLS, but it's certainly good
enough for voice communication protocols over UDP.

With a good hash function (one which does not permit the
length-extension attack), such as any of the SHA-3 finalists, H(k, m)
is a good MAC.


Robert Ransom