[12590] in cryptography@c2.net mail archive
Re: [Bodo Moeller ] OpenSSL Security
daemon@ATHENA.MIT.EDU (John Kelsey)
Wed Feb 26 10:28:05 2003
X-Original-To: cryptography@wasabisystems.com
X-Original-To: cryptography@wasabisystems.com
Date: Wed, 26 Feb 2003 01:37:02 -0500
To: Bill Frantz <frantz@pwpconsult.com>,
Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>,
Anton Stiglic <astiglic@okiok.com>
From: John Kelsey <kelsey.j@ix.netcom.com>
Cc: cryptography@wasabisystems.com, ietf-tls@lists.certicom.com
In-Reply-To: <v03110703ba8175358d0a@[192.168.1.5]>
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@ix.netcom.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
