[Bodo Moeller <bodo at openssl.org>] OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption
John Kelsey
kelsey.j at ix.netcom.com
Wed Feb 26 01:37:02 EST 2003
At 11:35 AM 2/25/03 -0800, Bill Frantz wrote:
...
>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, kelsey.j at ix.netcom.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com
More information about the cryptography
mailing list