conservative choice: encrypt then MAC (Re: general defensive crypto coding principles)

[Adam Back]

Don't forget Bleichenbacher's error channel attack on SSL
implementations, which focussed on the mac then encrypt design of
SSL... web servers gave different error for malformed padding vs
plaintext MAC failure.  The lesson I drew from that is the
conservative choice is encrypt then MAC.

I dont think encrypt then MAC presents a timing attack because your
chances of getting past the MAC are 1/2^80 in the first place.

And obviously you include the whole ciphertext (including the IV!) in
the MAC.  In fact anything which affects decryption process should be
in the mac.

Adam

On Thu, Feb 09, 2006 at 05:01:05PM +1300, Peter Gutmann wrote:
> Jack Lloyd <lloyd at randombit.net> writes:
> >Bellare and Namprempre have a paper on this [worth reading IMO;
> >http://www-cse.ucsd.edu/~mihir/papers/oem.html] which suggests that this
> >method (which they term Encrypt-and-MAC) has problems in terms of information
> >leakage. An obvious example occurs when using a deterministic authentication
> >scheme like HMAC - an attacker can with high probability detect duplicate
> >plaintexts by looking for identical tags. They also show that using a MAC on
> >the ciphertext is a secure construction in a fairly broad set of cases.
> 
> Here's a trivial way in which it can be weaker: Let's say you MAC the
> ciphertext and if it checks out OK you decrypt it and use it.  If you're using
> any mode other than ECB (which you'd better be doing) an attacker can
> arbitrarily modify the start of the message by fiddling with the IV.  CBC (by
> far the most widely-used mode) is particularly nasty because you can make the
> decrypted data anything you want, as the IV is xored directly into the
> plaintext.  So you can use encrypt-then-MAC, but you'd better be *very*
> careful how you apply it, and MAC at least some of the additional non-message-
> data components as well.
> 
> Another problem with encrypt-then-MAC is that it creates a nice timing channel
> if you bail out on a MAC failure before doing the decryption step.  So while
> EtM may be theoretically better in some (somewhat artificial) cases, it's much
> more brittle in terms of implementation problems.  Since implementors are
> rarely expert cryptographers, I'd prefer the safer MtE rather than EtM for
> protocol designs.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com