Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN | Hacker News Reader

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

sweet32.info

140 pointspedro8441 comments

To put this in context: You should have been avoiding 64-bit block ciphers to begin with.

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.

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.

> 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.)

> 2^64 bytes

18446.74 PB

GCM has trouble after just 72PB, because of the way the initial block is divided between counter and IV.

Where are you getting that number?

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.

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).

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.)

even if we would. that could easily be defeated by regular rekeying like done in ipsec or not?

My hope is that, by then, we'd be using 256-bit blocks so we don't need to worry about it.

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

[2] http://dx.doi.org/10.7146/dpb.v23i485.6978

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

The researcher site is https://sweet32.info/

And RedHat has a nice writeup as well: https://access.redhat.com/articles/2548661

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

The OpenVPN Hardening wiki says 3DES-EDE is still fine

https://community.openvpn.net/openvpn/wiki/Hardening

Has the OpenVPN wiki been reviewed and updated to reflect SWEET32?

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/ChangesInOpenvpn2...

> The OpenVPN Hardening wiki says 3DES-EDE is still fine

Last modified 2 years ago

Sites that want to support IE8 on XP while disabling RC4.

https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...

sigh

Thank you, IE, for once again royally screwing all of us over.

Then drop support.

I'm not the one writing for it, and I'm not the one who's forced to support it by their employers.

Well then it seems a little exaggerated to say "all of us", no?

If you lump this in with all of the other effects IE has had on internet standards over the years, then it is accurate enough.

It's holding back positive progress in a number of fields.

More precisely, XP SChannel.

Careful. "Everyone" knows not to use DES, but lots of people still think Blowfish is OK. The problem is 64-bit blocks, not DES in particular.

There are related problems in CTR constructions, including modern stuff like AES-GCM (the number of bytes you need to encrypt is far bigger, but the security consequences are worse).

Well, yes. That's why the official recommendation from Schneier has been at least Threefish forever.

PCI-DSS says 112 bits of security is "strong cryptography", just so people can continue using 3DES.

Strictly speaking, 112 bits of "security" is "strong" enough. The problem is this is usually measured as the log (base 2) of the number of possible secret keys. It ignores:

  - Block size  <- YOU ARE HERE
  - Cipher mode
  - Cipher construction and integrity checks (for non-AEAD modes)
  - Key exchange

You can break 256 bit AES if you're using 256-bit classical Diffie Hellman, for example. "But AES has 256 bits of security!" is somewhat silly to argue in such a hypothetical protocol.

This is one reason why you're better off ignoring PCI-DSS when it comes to cryptography guidelines (aside from maintaining compliance where you have obligations to remain compliant, of course).

Per the wiki:

The electronic payment industry uses Triple DES and continues to develop and promulgate standards based upon it (e.g. EMV).

https://en.wikipedia.org/wiki/Triple_DES

...that's terrifying.

maybe not, because if triple DES were so unsafe wouldn't there be a lot more theft?

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

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

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.

Why did Openssl only disable TDES and not Blowfish?

Is there a browser that supports a Blowfish ciphersuite?

No, but it's the OpenVPN default, so unencrypted traffic over OpenVPN might be interesting to play with.

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 [2] https://testssl.sh/openssl-rfc.mappping.html [3] https://tls.mbed.org/supported-ssl-ciphersuites [4] 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.

We changed the URL from 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-we..., via https://news.ycombinator.com/item?id=12353314.

Reply on news.ycombinator.com