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

[Marsh Ray <[e-mail]>]

From: Robert Ransom [mailto:[e-mail]]
Sent: Friday, November 15, 2013 11:43 AM
> 
> 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?

One would certainly hope the properties would still hold when used with actual hash functions which differ from an ideal hash function in a subset of ways.

ISTR one of the original NIST requirements for SHA-3 was that it be compatible with existing constructions like HMAC. On the other hand, NIST seemed to feel that some of the other original requirements were still negotiable (e.g., preimage resistance of two times collision resistance).

NIST suggests they will standardize a specific MAC mode for SHA-3. I haven't heard anything to suggest this provides any security advantage over HMAC, just a little more performance for short messages.

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

Intuitively that makes sense as a descriptive term.

But I find for myself that having such an attractive term around is a dangerous temptation!

My search engine turns up only one hit for the term:
http://crypto.stackexchange.com/questions/5589/speeding-up-partially-known-plaintext-preimage-recovery-attack-on-md5

I think it's a reasonable question and the asker gets a good answer, but I would much rather see it defined a bit more formally. It probably has been somewhere.

> There are plenty of other defensible choices for a MAC.

Yeah, I didn't mean to imply so much that HMAC is the One True MAC or that integrated AE modes can never be defensible. Just that MAC-(then|and)-Encrypt are broken while Encrypt-then-HMAC is a very conservative design which has stood the test of time and emerged victorious.

See: https://twitter.com/elwoz/status/401135814307889152
Figure 2 from http://eprint.iacr.org/2000/025

> 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]).

What *doesn't* look good if we restrict our discussion to configurations which have explicit hardware support?

Wait...I'll answer that: RC4 :-)
 
> 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.

What if (as in the TLS handshake) m itself was used to negotiate the length of k?

- Marsh
Usual disclaimers apply.