6 ms·

As much as we see AES-GCM, this particular observation has concerned me: "The GCM slide provides a list of pros and cons to using GCM, none of which seem like

• diamondlovesyou 5y ago
  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)?
• api 5y ago
  SIV modes fix this.
  • tptacek 5y ago
    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.
    • api 5y ago
      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.
      • tptacek 5y ago
        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.
        • tptacek 5y ago
          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).
        • bawolff 5y ago
          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.
          • aidenn0 5y ago
            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.
• Aachen 5y ago
  > 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.
  • chasil 5y ago
    I was actually thinking of a rowhammer attack on the counter.
    • Aachen 5y ago
      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!
  • tptacek 5y ago
    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.)
  • 5y ago
• 1vuio0pswjnm7 5y ago
  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)