Hacker News Reader

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

For more info see for example:

* https://www.cs.uaf.edu/2012/fall/cs441/students/sc_ps3.pdf

* A presentation at CCC about how hackers broke the different security features or PS3 including ECDSA https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2...

https://xkcd.com/221/

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

I was actually thinking of a rowhammer attack on the counter.

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!

That submission illustrates a common, bizzare thinking pattern seen with programmers. "Everything else sucks" so they adopt solution X. Then other programmers start to criticise solution X. "Monoculture", "fanboyism" or whatever the lingo. Meanwhile everyone forgets about why "everything else sucks". Other programmers will even try to counter the allegation that everything else sucks, as if it were not true.

"Everything else sucks" is why I "settle" for volunteer-supported, free, UNIX-like OS. It is why I "settle" for using djb's software (the stuff IETF would never approve of, not just the crypto work). It does not mean I think that these solutions are ideal in any objective sense. It means "everything else sucks". And when these solutions help me avoid the pain of having to use "everything else", then it stands to reason they will appear not only better than everything else but even high quality in an objective sense. (To use Gutmann's analogy, the oasis looks refreshing, regardless of the actual water quality.)

Another example are the discussions on the k language/intepreter on HN. Commenters would focus on crticisms of k instead of considering why other solutions cannot achieve the same performance. As one person put it, the question should not be "Why is this so concise and fast?" but "Why is everything else so bloated and slow?" (paraphrasing)

If this particular failure mode is so easy to crack, why is testing specifically for this failure mode not acceptable (ie via continuous integration testing)?

SIV modes fix this.

SIV mode (mostly) fixes this by (usually) jettisoning most of the benefit of using GCM in the first place, which is that it is very fast when hardware-accelerated.

Compared with large random nonces, I think nonce-misuse-resistance is somewhat oversold.

No it doesn't. SIV is almost as fast as AES-GCM when implemented with AES-CTR and GMAC (in my benchmarks on x64 and Apple M1). It requires two passes to encrypt but on the second pass the packet is in L1 cache already.

EDIT: nonce misuse resistance is IMHO a robustness thing. Yes large nonces give you similar bounds, but there are numerous banana peels like cloning VMs, live migration, IoT devices with bad PRNGs, incorrectly implemented concurrent counters, concurrent counters that work fine on x64 and fail on ARM, etc. that can cause nonce reuse.

Sudden death from nonce reuse just give me the willies. Kind of a big footgun.

I honestly don't care if you want to use straight SIV, AES-GCM-SIV, or some hand-rolled in-between SIV. SIV is fine. But it's not GCM.

To your additions to the comment above: the point of large nonces is that you always just use random nonces; you retain the RNG point of failure (which you almost certainly have anyways) but you don't have the "concurrent counters" problem anymore, since you're never going to use counters as a nonce (or, if you do, you do so in addition to a 128 bit random nonce).

A nice property of the XChaCha+Blake scheme proposed here is that Blake doesn't have any nonce dependency at all, and most of the terror of nonce misuse comes from how the MAC deals with repeated nonces, not how the underlying stream cipher does (though, obviously, a reliably repeating nonce gives you a pretty devastating confidentiality failure).

That may be true, but does it really matter? The name of the cryptosystem seems pretty irrelavent unless you have some compliance checkbox to check.

It makes the "SIV fixes this" a non-sequitur. "SIV fixes this" is like saying "not using GCM fixes this" which (for avoiding a problem in GCM) is somewhat uninteresting.

Actually you're right. I was equivocating because there are SIV modes that use GMAC, the MAC component of GCM, for its performance benefits on hardware.