> the single biggest, indeed killer failure of the whole mode, the fact that if you for some reason fail to [implement a core and simple feature of the mode], you're sending what's effectively plaintext (it's recoverable with a simple XOR). It's an incredibly brittle mode
I think most people would agree about that if you omit parts of cryptographic algorithms, it is not surprising that it's now broken.
Also who even implements GCM by hand? Who's supposed to forget to increment that counter?
> the equivalent of the historically frighteningly misuse-prone RC4
Libraries let you call RC4(data, key) and it would work as designed. It was up to you to realize that you shouldn't reuse the key. With GCM, incrementing the counter is done in the library and not exposed for you to forget.
Don't roll your own crypto is the only takeaway here.
> With GCM, incrementing the counter is done in the library and not exposed for you to forget.
GCM has two counters, the message-block-counter (4 bytes), and the message counter / nonce (12 bytes). The former is inside the crypto library, the latter is supplied by the client and can be mismanaged like any other IV.
isn't this what happened to the ps3? the documentation said "use a random number" and they calculated it once and put it as a constant instead of...yah know...using a random number (each time)?
In the PS3 they lacked a real random number in ECSDA computation. That effectively broke the signature and actually made it possible to recover the private key.
I think Guttman is referring to the GCM nonce when he talks about the "counter"; GCM has a famously short nonce, so the common advice is to use an incrementing counter as your nonce rather than risk colliding random nonces. In that context, "forgetting to increment the counter" is a huge footgun, not a "core and simple feature of the mode".
(You can't really forget to increment the underlying CTR counter; your system won't work.)
That might be a valid thing to defend against by using specific algorithms that protect against it, but that's distinct from what you wrote about it being easy to forget to implement a crucial part of it. Everything in cryptography is easy to get wrong, that's why we use tested libraries. But if there is new advice on protecting against attacks like spectre, rowhammer, and others that exploit hardware problems, I'd be interested to learn more. If you have a blog or paper where someone explores the fragility of different algorithms in that regard, let me know!
I think most people would agree about that if you omit parts of cryptographic algorithms, it is not surprising that it's now broken.
Also who even implements GCM by hand? Who's supposed to forget to increment that counter?
> the equivalent of the historically frighteningly misuse-prone RC4
Libraries let you call RC4(data, key) and it would work as designed. It was up to you to realize that you shouldn't reuse the key. With GCM, incrementing the counter is done in the library and not exposed for you to forget.
Don't roll your own crypto is the only takeaway here.