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.
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.)
> 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).
(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.)
OpenSSL developer Mark Cox says: "tldr: "Low", Don't Panic!"
The researcher site is https://sweet32.info/
And RedHat has a nice writeup as well: https://access.redhat.com/articles/2548661
Thank you, IE, for once again royally screwing all of us over.
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).
- Block size <- YOU ARE HERE
- Cipher mode
- Cipher construction and integrity checks (for non-AEAD modes)
- Key exchange
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).
The electronic payment industry uses Triple DES and continues to develop and promulgate standards based upon it (e.g. EMV).
Last modified 2 years ago
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
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.
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.
Some sources, some old, some new -- you'd reasonably expect Blowfish to be an older suite if it exists:
 https://testssl.sh/mapping-rfc.txt  https://testssl.sh/openssl-rfc.mappping.html  https://tls.mbed.org/supported-ssl-ciphersuites  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.
There's also http://blog.cryptographyengineering.com/2016/08/attack-of-we..., via https://news.ycombinator.com/item?id=12353314.