Re: [ietf-tls] Re: an attack against SSH2 protocol
Thus spake Wei Dai: > I'll note that using CTR mode is more efficient than either of these > suggestions. It doesn't require unpredictable IVs. ... > Good point. If we want to fix SSH by using a per-packet unpredictable IV, > the IV would have to be added to the list of MAC inputs. I think that > would prevent the attack in appendix C. So is the correct approach to fix the CBC implementation, or to switch to a mode that is less prone to misuse? > I'm not very familiar with how IETF working groups work, so what's the > next step here? Someone writes an internet-draft (ie. RFC format) describing the change. S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSSalways said exactly what pleased me." --Albert Einstein __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ietf-tls] Re: an attack against SSH2 protocol
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. I'll note that using CTR mode is more efficient than either of these suggestions. It doesn't require unpredictable IVs. > 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) Good point. If we want to fix SSH by using a per-packet unpredictable IV, the IV would have to be added to the list of MAC inputs. I think that would prevent the attack in appendix C. I'm not very familiar with how IETF working groups work, so what's the next step here? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ietf-tls] Re: an attack against SSH2 protocol
On Fri, 8 Feb 2002, Bodo Moeller wrote: > In TLS, the "IV for subsequent records is the last ciphertext block > from the previous record" [RFC 2246], and plaintext blocks usually > consist of raw application data followed by a MAC, so the attack > applies. (Having the MAC at the *beginning* of each packet would > avoid the attack.) > > In his CRYPTO 2001 paper "The Order of Encryption and Authentication > for Protecting Communications (or: How Secure Is SSL?)", Hugo Krawczyk > supposedly shows that SSL/TLS with CBC encryption is secure -- but > he assumes a random IV for each encrypted block, which is not how the > actual SSL protocol works. Bodo's observation is correct. My paper essentially assumes a random IV per message. Without it (i.e. with the specification of using the last ctext block from msg i as the IV of msg i+1) CBC mode is NOT even secure against chosen plaintext attacks! In this case even MACing the ciphertext does not help. 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. > > Another problem with CBC as used in SSL/TLS was pointed out by Serge > Vaudenay, see 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. 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 wonder if any one cares in ssl/tls community about all these basic crypto-security design issues; any plans for future protocol versions? Hugo 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) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ietf-tls] Re: an attack against SSH2 protocol
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 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. 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 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]
Re: an attack against SSH2 protocol
Wei Dai <[EMAIL PROTECTED]>: >> [Posted to sci.crypt and the IETF SSH working group mailing list.] >> >> Phil Rogaway observed that CBC mode is not secure against chosen- >> plaintext attack if the IV is known or can be predicted by the attacker >> before he choses his plaintext [1]. Similarly, CBC mode is not secure if >> the attacker can observe the last ciphertext block before choosing the >> next block of plaintext, because the last block of ciphertext >> essentially serves as the IV for the rest of the message. >> >> The attack itself is very simple. Remember that in CBC mode, each >> plaintext block is XOR'ed with the last ciphertext block and then >> encrypted to produce the next ciphertext block. Suppose the attacker >> suspects that plaintext block P_i might be x, and wants to test whether >> that's the case, he would choose the next plaintext block P_j to be x >> XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j >> XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his >> guess by looking at whether C_j = C_i. >> >> The SSH2 protocol, when used with a block cipher in CBC mode, does allow >> the attacker to observe the last ciphertext block of a packet, which is >> then used as the (implicit) IV of the next packet. [...] >> [1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt > I have received some comments through private email. Apparently the exact > same weakness was known for IPSec and may also exist in TLS (I haven't > read enough of its RFC to be sure) [...] In TLS, the "IV for subsequent records is the last ciphertext block from the previous record" [RFC 2246], and plaintext blocks usually consist of raw application data followed by a MAC, so the attack applies. (Having the MAC at the *beginning* of each packet would avoid the attack.) In his CRYPTO 2001 paper "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Hugo Krawczyk supposedly shows that SSL/TLS with CBC encryption is secure -- but he assumes a random IV for each encrypted block, which is not how the actual SSL protocol works. Another problem with CBC as used in SSL/TLS was pointed out by Serge Vaudenay, see 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. -- 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]
