[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