...
I have always preferred to have the MAC check as much of the transfer logic as possible. If you pad-then-MAC-then-encrypt, then the MAC checks both the encryption and decryption stages. If you MAC last, all the MAC checks is whether errors have been introduced into the transmission (by an attacker or just through failure of the TCP checksum).
Right. But it's not hard to set things up so that you can prove that there is no way for the decrypted, unpadded plaintext to change without the padded ciphertext having changed. (Basically, you just have to include the IV in the MAC along with the padded ciphertext, and use a padding rule that's unambiguous.) In theory, there's no security advantage doing it this way, since you can get the same proofs doing it both of the other obvious ways. In practice, though, this way the implementation has only one thing to get right--verify the MAC before you do anything else. Otherwise, the implementation may have to get all sorts of other stuff right--checking the padding correctly, dealing with the effects of altered decrypted plaintext on compression schemes, etc.
The spec that says how to do the encryption/padding/MACing will probably be reviewed by other cryptographers, who will generally know about reaction attacks. It's much less likely that any implementation will be reviewed by someone who understands these attacks.
Cheers - Bill
--John Kelsey, [EMAIL PROTECTED]
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
