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