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

[Jerry Leichter]

>> 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....
Well, we really are off into the woods here.

The paper to refer to is http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.5488&rep=rep1&type=pdf

Extracting the summary of the results:
---------------------------------------------
The *generic insecurity of AtE*.  We show that the authenticate-then-encrypt method (as in SSL) is not generically secure under the sole assumption that the encryption function is secure against chosen plaintext attacks and the MAC secure against chosen message attacks.  We show an example of a simple encryption function that enjoys perfect (in the sense of Shannon) secrecy against chosen plaintext attacks and when combined under the AtE method with any MAC (even a perfect one) results in a totally breakable implementation of secure channels.

The *generic insecurity of E&A*.  The above example is used also to demonstrate the insecurity of the encrypt-and-authenticate method (as in SSH) where the same attack (and consequences) is possible.

The *security of AtE with specific encryption modes*.  This paper does not bring just bad news. We also show that the authenticate-then-encrypt method is secure under two very common forms of encryption: CBC mode (with an underlying secure block cipher) and stream ciphers (that xor the data with a random or pseudorandom pad).

A separate paper by Canetti and Krawczyk, on the other hand, shows that (under similar assumptions about the primitives), *encrypt-then-authenticate is a generically secure*.
---------------------------------------------

Yes, the encryption functions used in the proof of *generic* insecurity are rather artificial and would never be used in practice.  But the power of the result should make you at least concerned.  Conversely, since we have a proof of security for encrypt-then-authenticate, unless you have some specific reason to use authenticate-then-encrypt - why not use it?

Note that the state of the art has moved on, and we now have *specific* "E&A" modes that are provably secure, and do less work in general than the separated modes.  (There are issues with complexity of implementation resulting in brittleness with some modes, and with patents for one of the best.)

Too often in this field, we come down to absolute statements:  Do this.  Don't do that.  The story is often more subtle than can be captured in such statements.  That doesn't make them wrong - just incomplete (and *sometimes* wrong).
                                                        -- Jerry