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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
