Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

["Paterson, Kenny" <[e-mail]>]

On 14/11/2013 16:21, "Martin Rex" <[e-mail]> wrote:

>Ralf Skyper Kaiser wrote:
>>
>> With EtA you need to trust the MAC. With AtE you need to trust the
>>cipher
>> _and_ the MAC.
>
>I believe you're confused.
>
>The MAC provides integrity protection, the Encryption provides
>confidentiality.  The quality of the MAC has exactly Zero impact
>on the confidentiality provided by the Encryption.

Unfortunately, you're completely wrong. The MAC is also necessary to
preserve confidentiality in the face of active attacks. It's a very common
misunderstanding amongst novice cryptographers to believe that there's a
separation:

	MAC <-> integrity
	Enc <-> confidentiality

If you need an example, consider the security history of IPsec's
encryption-only modes. (Am I allowed to mention IPsec on a TLS list? Well,
I just did.) 

These modes provide confidentiality against passive attackers, yes, but
they fail pretty spectacularly against active attackers. Bellovin was the
first to show that; the nadir for encryption-only IPsec came in my 2007
Oakland paper with Jean Paul Degabriele, full version here:

http://eprint.iacr.org/2007/125

(Just read the abstract if you've forgotten the headline.)

And, as far as I know, there are no significant attacks when IPsec is
configured in encrypt-then-MAC configurations (e.g. ESP conf+auth or ESP
followed by AH). On the other hand, all the configurations of IPsec where
the MAC is applied before the encryption are broken. (Another
demonstration that MAC-then-encrypt is not a robust choice.)

>For EtA, the characteristics&quality of the Cipher do not affect
>(and therefore can not improve) the quality of the MAC scheme
>at all.

That's true but irrelevant, unless you don't trust your MAC algorithm. So
why do you not trust HMAC-SHA256? Can you point to any shred of evidence
that it is weak in some way? That it is likely to become weak? That its
extensive security analysis is wrong? Without back-up of this kind, your
argument is just hot air. See also Marsh Ray's recent post.

>For AtE, the characteristics&quality of the Cipher additionally
>strengthen the quality of the MAC scheme, so weaknesses in the MAC
>scheme do not immediately translate into a vulnerability.

That's true too, but should be accorded small weight in the argument given
the litany of attacks against MAC-then-encrypt constructions.

>Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
>that does not have cryptographic hash properties (2nd paragraph Page 10):
>
>  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
>
>  GHASH is a keyed hash function but not, on its own, a cryptographic
>  hash function. This Recommendation only approves GHASH for use within
>  the context of GCM.
>
>The use of GHASH without cryptographic protection would not be safe.
>

Also true. But guess what? In GCM, the GHASH MAC is computed on the
ciphertext! The GHASH output is then encrypted using a further invocation
of the block cipher. Where does this leave your argument in favour of
MAC-then-encrypt?

Kenny