Anton Stiglic <[EMAIL PROTECTED]>: > If SSL required encrypt-then-MAC, a programmer > would more naturally start by verifying the MAC, then decrypt > the message, so Vaudenay's attack would be caught first by > the MAC verification and the implementation would probably > return an error after the MAC verification and not leak the > information needed to discover the plaintext.
Actually there are three choices: Pad-then-encrypt-then-MAC Pad-then-MAC-then-encrypt MAC-then-pad-then-encrypt It's true that pad-then-encrypt-then-MAC appears to be the safest approach in general, but pad-then-MAC-then-encrypt would also have avoided these attacks. Unfortunately, SSL 3.0 and TLS 1.0 use MAC-then-pad-then-encrypt. > So even though the attack is not directly the result of the SSL > protocol spec, In a sense it is: as the block cipher padding is not to be included in the MAC computation, you don't really know what bytes to compute a MAC on before you have looked at the padding. If the adversary can count exactly how many input blocks are fed to HMAC, then you have a problem that you cannot easily work around. The attack demonstrated by Vaudenay et al. users a less subtle timing difference (the difference between a MAC on about 256 SHA-1 input blocks and no MAC at all), but switching to Pad-then-MAC-then-encrypt should be considered for TLS 1.1. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]