On Wed, Feb 13, 2002 at 03:57:59PM +0200, Hugo Krawczyk wrote: [...] > Thus, future revisions of TLS should also take this into account. > That is, either transmit a fresh (unpredictable) IV with each msg, > or implcitly compute this IV in an *unpredictable* way, for example by > applying a prf to the msg counter.
What about using the MAC as a prefix instead of postfix to the plaintext? If the MAC is secure, it certainly will be unpredictable, so the encrypted MAC (which is the effective IV for the actual data) will be unpredictable as well. >> Another problem with CBC as used in SSL/TLS was pointed out by Serge >> Vaudenay, see <URL:http://www.openssl.org/~bodo/tls-cbc.txt>. That >> one can easily be avoided by implementations. To avoid the new attack >> without changing the protocol definition, implementations would have >> to send an empty fragment before application data to ensure IV >> randomization. > This is a nice attack (do you know of a publicly available paper on this > that I can cite?), and indeed easier to fix than the others. It's now a technical report: Serge Vaudenay CBC Padding: Security Flaws in SSL, IPSEC, WTLS, ... DSC Technical Report 200150, EPFL, 2001. <URL:http://lasecwww.epfl.ch/query.msql?ref=Vau01> > The analytical model in my paper (for the case of > authenticate-then-encrypt with CBC) makes the assumption that decryption > and mac verification are performed as an atomic operation with a single > "ciphertext invalidity" bit learned by the attacker regardless of the > reason for failure. This points out to yet another advantage of the > encrypt-then-mac approach, namely, there you first check the MAC and if > not valid you do NOT decrypt (in particular, you provide no info to the > other side or the atacker about the result of decryption). No need for > assumptions on the atomicity of combined operations. I agree, this is a nice property. > I wonder if any one cares in ssl/tls community about all these > basic crypto-security design issues; I certainly do -- > any plans for future protocol > versions? so I was going to ask this myself. > PS: since Wei Dai mentioned the case of SSH in this context, the bad news > there is that even using CBC and fixing the problem of predictable IV > leaves the protocol open to the attacks on authenticate-and-mac > showed in my paper (e.g. the attack in appendix C) Previously I had only mentioned the CRYPTO 2001 version of the paper (which does not have an Appendix C). Here's a pointer to the full paper: Hugo Krawczyk The order of encryption and authentication for protecting communications (Or: how secure is SSL?) Cryptology ePrint Archive: Report 2001/045 <URL:http://eprint.iacr.org/2001/045/> -- 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
