general defensive crypto coding principles

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Feb 8 23:01:05 EST 2006


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.

Peter.

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



More information about the cryptography mailing list