[Cryptography] Literature on reusing same key for AES / HMAC?

[John-Mark Gurney]

Krisztin Pintr wrote this message on Sun, Nov 08, 2015 at 18:43 +0100:
> John-Mark Gurney (at Sunday, November 8, 2015, 6:29:44 PM):
> >> resuing the key is something like
> >> AES(K, M) || HMAC-SHA256(K, M)
> 
> > This is Mac then encrypt which is recommended NOT to be used.
> 
> this was not the point at all, and you can fix it for yourself:
> 
> AES(K, M) || HMAC-SHA256(K, AES(K, M))
> 
> 
> but as you brought it up, the notion that encrypt-then-MAC would be
> the secure option over mac-then-encrypt is just as false the other
> weird recommendations we often hear. in fact they are both equally
> secure if implemented right. the only difference is when you implement
> them wrong, you are more likely to get away with it with enc-then-mac.
> in particular, since you detect malicious activity early, you simply
> don't do most of the processing, and thus avoid any bugs or
> insecurities there. but it is a patchwork. the implementation must be
> solid regardless.

Yes, if implemented correctly, AtE can be secure, but as attacks like
the CBC Padding oracle attack shows, mistakes are made, and
implementations are never 100% perfect.

In my book, if changing to EtA fixes a whole class of problems, it's
a good thing, and should be recommended.

> just to give an example, keccak guys recommend a single pass
> authenticated encryption. this is encrypt-and-mac, but it is as secure
> as it gets. also, we have the CAESAR competition, in which many (all?)
> candidates are also encrypt-and-mac. so obviously, actual
> cryptographers don't know about the enc-then-mac rule, only the
> blogosphere does.

Having learned the EtA rule from a cryptographer, I'd disagree that
crytographers don't know the EtA rule...

The fact that TLS is switching away from AtE (see RFC7366) speaks
loudly..


-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."