Hacker News Reader

Comment by CiPHPerCoder | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com