6 ms·

Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN

140 points by pedro84 10y ago

pedro84 10y ago
From the article: "But the take-away is this: triple-DES should now be considered as “bad” as RC4." OpenSSL developer Mark Cox says: "tldr: "Low", Don't Panic!" https://twitter.com/iamamoose/status/768431734547484672 https://twitter.com/iamamoose/status/768431734547484672 The researcher site is https://sweet32.info/ https://sweet32.info/ And RedHat has a nice writeup as well: https://access.redhat.com/articles/2548661 https://access.redhat.com/articles/2548661
CiPHPerCoder 10y ago
To put this in context: You should have been avoiding 64-bit block ciphers to begin with. https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad Furthermore, as the article says from the getgo, birthday attacks are not new. They are a known problem. What's new is someone wrote a paper describing a practical attack, and actually bothered to generate enough traffic to exploit the birthday bound of a 64-bit block cipher. Your takeaway from this should be: - If it's not AES or CHACHA20, disable it. - If it's not AES_GCM or CHACHA20_POLY1305, consider disabling it.
- espadrine 10y ago
  To me, the takeaway is that assumptions made for certain algorithms may lose their validity within ten years. Exchanging 32GB over the Internet was absurd in 1993, when Blowfish was published. With video becoming a bigger part of the Web and Internet speeds going up, it may eventually stop being that way.
  - CiPHPerCoder 10y ago
    > To me, the takeaway is that assumptions made for certain algorithms may lose their validity within ten years. If we hit 2^64 bytes transferred in under one hour as a norm before 2030, I'll be immensely surprised. (This would implicate 128-bit block ciphers for birthday collisions.)
    - emilburzo 10y ago
      > 2^64 bytes 18446.74 PB
      - tptacek 10y ago
        GCM has trouble after just 72PB, because of the way the initial block is divided between counter and IV.
        sdevlin 10y ago
        Where are you getting that number?
        tptacek 10y ago
        The Noise framework documentation. I know there's "a" number for GCM, but I always forget what it is, so I keep going back to Noise.
        deleted 10y ago
        [deleted]
        sdevlin 10y ago
        I don't think their bound is related to nonce-management issues. From the documentation: > The GCM security limit is 2^56 bytes because: > This is 2^52 AES blocks (each block is 16 bytes). The limit is based on the risk of birthday collisions being used to rule out plaintext guesses. The probability an attacker could rule out a random guess on a 2^56 byte plaintext is less than 1 in 1 million (roughly (2^52 * 2^52) / 2^128).
        tptacek 10y ago
        Yep. I'm wrong. I'll stop sourcing that number from Noise. :) (Clarified offline: I'm thinking of the 32 bit counter in GCM, which will wrap in tens of gigabytes worth of bytes under a single nonce. Not a TLS issue, a concern for custom protocols.)
- pbsd 10y ago
  Some extra context: here's Maurer [1, §4], in 1991, describing the same property exploited here, on a generic class of CBC-like functions. Also, Knudsen [2, §4.4] on his 1994 PhD thesis. I believe Schneier et al.'s 'Practical Cryptography' also mentioned this. The Sweet32 paper only mentions papers from 2011 and 2012, so one might be mislead to believe this was something relatively new. [1] https://dx.doi.org/10.1007/3-540-46416-6_39 https://dx.doi.org/10.1007/3-540-46416-6_39 [2] http://dx.doi.org/10.7146/dpb.v23i485.6978 http://dx.doi.org/10.7146/dpb.v23i485.6978
  - deleted 10y ago
    [deleted]
shiftoutbox 10y ago
. - = STOP NAMING EXPLOITS SOMETHING CUTE = - .
qwertyuiop924 10y ago
Who's still using 3DES? That should already be a shooting offense anywhere where security matters.
- forbiddenlake 10y ago
  The OpenVPN Hardening wiki says 3DES-EDE is still fine https://community.openvpn.net/openvpn/wiki/Hardening https://community.openvpn.net/openvpn/wiki/Hardening
  - tedunangst 10y ago
    Has the OpenVPN wiki been reviewed and updated to reflect SWEET32?
    - subliminalpanda 10y ago
      Their latest release now actively discourages 64 bit block ciphers: Steffan Karger (4): Fix polarssl / mbedtls builds Don't limit max incoming message size based on c2->frame Fix '--cipher none --cipher' crash Discourage using 64-bit block ciphers https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3.12 https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn2...
  - mhurron 10y ago
    > The OpenVPN Hardening wiki says 3DES-EDE is still fine Last modified 2 years ago
- hsivonen 10y ago
  Sites that want to support IE8 on XP while disabling RC4. https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP&key=101 https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...
  - qwertyuiop924 10y ago
    sigh Thank you, IE, for once again royally screwing all of us over.
Panino 10y ago
Yet another example of key size not being the only thing to consider. Also: OpenVPN's default cipher is blowfish? That would have been a great choice 20 years ago, but not now. It shouldn't even be supported in 2016.
yalogin 10y ago
Why did Openssl only disable TDES and not Blowfish?
- tptacek 10y ago
  Is there a browser that supports a Blowfish ciphersuite?
  - CiPHPerCoder 10y ago
    No, but it's the OpenVPN default, so unencrypted traffic over OpenVPN might be interesting to play with.
- niftich 10y ago
  There are no TLS or SSL ciphersuites that use Blowfish. Some sources, some old, some new -- you'd reasonably expect Blowfish to be an older suite if it exists: [1] https://testssl.sh/mapping-rfc.txt https://testssl.sh/mapping-rfc.txt [2] https://testssl.sh/openssl-rfc.mappping.html https://testssl.sh/openssl-rfc.mappping.html [3] https://tls.mbed.org/supported-ssl-ciphersuites https://tls.mbed.org/supported-ssl-ciphersuites [4] http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/ http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/ Also note that Bruce Schneier, Blowfish's creator, has been encouraging people to move off of it for years, since he went on to design two more block ciphers since.
dang 10y ago
We changed the URL from https://www.openssl.org/blog/blog/2016/08/24/sweet32/ https://www.openssl.org/blog/blog/2016/08/24/sweet32/ to this post because it seems more explanatory. There's also http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html http://blog.cryptographyengineering.com/2016/08/attack-of-we..., via https://news.ycombinator.com/item?id=12353314 https://news.ycombinator.com/item?id=12353314.
rasz_pl 10y ago
TLDR: ~800GB sniffed in one session to perform the attack. Only practical if you never log off your torrent VPN.
erichocean 10y ago
At what point does using TLS become malpractice? At what point does any software that links to OpenSSL become immediately suspect? And TLS as deployed isn't secure even when it works whenever you don't trust the certificate authorities. Which is always. Yes, I get that these are mega standards/libraries with a gazillion knobs, some of which are secure. But maybe kitchen sink crypto isn't the way to go? When will we say enough is enough and do something about it? For my part, I switched to using NaCl with public key pinning a few years ago and haven't looked back. /sigh

140 points by pedro84 10y ago

From the article: "But the take-away is this: triple-DES should now be considered as “bad” as RC4." OpenSSL developer Mark Cox says: "tldr: "Low", Don't Panic!" https://twitter.com/iamamoose/status/768431734547484672 https://twitter.com/iamamoose/status/768431734547484672 The researcher site is https://sweet32.info/ https://sweet32.info/ And RedHat has a nice writeup as well: https://access.redhat.com/articles/2548661 https://access.redhat.com/articles/2548661

CiPHPerCoder 10y ago

To put this in context: You should have been avoiding 64-bit block ciphers to begin with. https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad Furthermore, as the article says from the getgo, birthday attacks are not new. They are a known problem. What's new is someone wrote a paper describing a practical attack, and actually bothered to generate enough traffic to exploit the birthday bound of a 64-bit block cipher. Your takeaway from this should be: - If it's not AES or CHACHA20, disable it. - If it's not AES_GCM or CHACHA20_POLY1305, consider disabling it.

espadrine 10y ago
To me, the takeaway is that assumptions made for certain algorithms may lose their validity within ten years. Exchanging 32GB over the Internet was absurd in 1993, when Blowfish was published. With video becoming a bigger part of the Web and Internet speeds going up, it may eventually stop being that way.
- CiPHPerCoder 10y ago
  > To me, the takeaway is that assumptions made for certain algorithms may lose their validity within ten years. If we hit 2^64 bytes transferred in under one hour as a norm before 2030, I'll be immensely surprised. (This would implicate 128-bit block ciphers for birthday collisions.)
  - emilburzo 10y ago
    > 2^64 bytes 18446.74 PB
    - tptacek 10y ago
      GCM has trouble after just 72PB, because of the way the initial block is divided between counter and IV.
      - sdevlin 10y ago
        Where are you getting that number?
        tptacek 10y ago
        The Noise framework documentation. I know there's "a" number for GCM, but I always forget what it is, so I keep going back to Noise.
        deleted 10y ago
        [deleted]
        sdevlin 10y ago
        I don't think their bound is related to nonce-management issues. From the documentation: > The GCM security limit is 2^56 bytes because: > This is 2^52 AES blocks (each block is 16 bytes). The limit is based on the risk of birthday collisions being used to rule out plaintext guesses. The probability an attacker could rule out a random guess on a 2^56 byte plaintext is less than 1 in 1 million (roughly (2^52 * 2^52) / 2^128).
        tptacek 10y ago
        Yep. I'm wrong. I'll stop sourcing that number from Noise. :) (Clarified offline: I'm thinking of the 32 bit counter in GCM, which will wrap in tens of gigabytes worth of bytes under a single nonce. Not a TLS issue, a concern for custom protocols.)
pbsd 10y ago
Some extra context: here's Maurer [1, §4], in 1991, describing the same property exploited here, on a generic class of CBC-like functions. Also, Knudsen [2, §4.4] on his 1994 PhD thesis. I believe Schneier et al.'s 'Practical Cryptography' also mentioned this. The Sweet32 paper only mentions papers from 2011 and 2012, so one might be mislead to believe this was something relatively new. [1] https://dx.doi.org/10.1007/3-540-46416-6_39 https://dx.doi.org/10.1007/3-540-46416-6_39 [2] http://dx.doi.org/10.7146/dpb.v23i485.6978 http://dx.doi.org/10.7146/dpb.v23i485.6978
- deleted 10y ago
  [deleted]

shiftoutbox 10y ago

. - = STOP NAMING EXPLOITS SOMETHING CUTE = - .

qwertyuiop924 10y ago

Who's still using 3DES? That should already be a shooting offense anywhere where security matters.

forbiddenlake 10y ago
The OpenVPN Hardening wiki says 3DES-EDE is still fine https://community.openvpn.net/openvpn/wiki/Hardening https://community.openvpn.net/openvpn/wiki/Hardening
- tedunangst 10y ago
  Has the OpenVPN wiki been reviewed and updated to reflect SWEET32?
  - subliminalpanda 10y ago
    Their latest release now actively discourages 64 bit block ciphers: Steffan Karger (4): Fix polarssl / mbedtls builds Don't limit max incoming message size based on c2->frame Fix '--cipher none --cipher' crash Discourage using 64-bit block ciphers https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3.12 https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn2...
- mhurron 10y ago
  > The OpenVPN Hardening wiki says 3DES-EDE is still fine Last modified 2 years ago
hsivonen 10y ago
Sites that want to support IE8 on XP while disabling RC4. https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP&key=101 https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...
- qwertyuiop924 10y ago
  sigh Thank you, IE, for once again royally screwing all of us over.

Panino 10y ago

Yet another example of key size not being the only thing to consider. Also: OpenVPN's default cipher is blowfish? That would have been a great choice 20 years ago, but not now. It shouldn't even be supported in 2016.

yalogin 10y ago

Why did Openssl only disable TDES and not Blowfish?

tptacek 10y ago
Is there a browser that supports a Blowfish ciphersuite?
- CiPHPerCoder 10y ago
  No, but it's the OpenVPN default, so unencrypted traffic over OpenVPN might be interesting to play with.
niftich 10y ago
There are no TLS or SSL ciphersuites that use Blowfish. Some sources, some old, some new -- you'd reasonably expect Blowfish to be an older suite if it exists: [1] https://testssl.sh/mapping-rfc.txt https://testssl.sh/mapping-rfc.txt [2] https://testssl.sh/openssl-rfc.mappping.html https://testssl.sh/openssl-rfc.mappping.html [3] https://tls.mbed.org/supported-ssl-ciphersuites https://tls.mbed.org/supported-ssl-ciphersuites [4] http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/ http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/ Also note that Bruce Schneier, Blowfish's creator, has been encouraging people to move off of it for years, since he went on to design two more block ciphers since.

dang 10y ago

We changed the URL from https://www.openssl.org/blog/blog/2016/08/24/sweet32/ https://www.openssl.org/blog/blog/2016/08/24/sweet32/ to this post because it seems more explanatory. There's also http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html http://blog.cryptographyengineering.com/2016/08/attack-of-we..., via https://news.ycombinator.com/item?id=12353314 https://news.ycombinator.com/item?id=12353314.

rasz_pl 10y ago

TLDR: ~800GB sniffed in one session to perform the attack. Only practical if you never log off your torrent VPN.

erichocean 10y ago

At what point does using TLS become malpractice? At what point does any software that links to OpenSSL become immediately suspect? And TLS as deployed isn't secure even when it works whenever you don't trust the certificate authorities. Which is always. Yes, I get that these are mega standards/libraries with a gazillion knobs, some of which are secure. But maybe kitchen sink crypto isn't the way to go? When will we say enough is enough and do something about it? For my part, I switched to using NaCl with public key pinning a few years ago and haven't looked back. /sigh