And my claim is that is not always valuable to an attacker, whereas I can't think of an instance where a repeated CTR nonce wasn't game-over.
It's always bad. I don't want to get into a semantic argument about whether or not a repeated IV is a vulnerability. It is. But it's not as severe a vulnerability as a repeated CTR nonce, which repeats the entire keystream.
> whereas I can’t think of an instance where a repeated CTR nonce wasn’t game-over.
The fact that you can’t think of an example is not a serious security argument. This is why we have rigorous security definitions rather than hand waving “I can’t think of anything” arguments, which should have died in the 90s.
I already gave you one example: key-wrapping. JOSE (of course) has a key-wrapping mode based on GCM, and at least one recent article advocates for its widespread use [1] (see recommendations at end). Despite me not agreeing with that advice, it is an example of where CTR loses no information at all under nonce reuse: the XOR of two random keys is itself indistinguishable from random.
I can certainly think of examples based on encrypting binary data streams where the XOR of plaintexts may also reveal very little. To decide whether CBC or CTR leaks more you have to consider the specifics of the application, or you have to make shaky assumptions about “typical” data. IMO those assumptions are not a good foundation for security and we should move past them.
In practice nonce reuse with CTR+GCM virtually always results in an obvious exploitable vulnerability. With CBC+HMAC nonce reuse sometimes results in an obvious exploitable vulnerability but often results in a system which has unclear security properties but which isn't known to be practically exploitable under common use (and may even still be provably secure under after careful analysis).
In other words, if the latter system is flawed it ends up having the sort of security properties more akin to physical security rather than the strong mathematical assurances we expect from cryptographic systems.
Given the high rate of issues with nonce mishandling in real systems, even ones that appeared to be carefully engineered, it shouldn't be hard to understand why systems engineers (as opposed to, say, cryptographic researchers) would have an unambiguous preference for one over another when it comes to practical systems, at least if all else were equal (which, of course, it seldom is!).
> IMO those assumptions are not a good foundation for security and we should move past them.
No one here is advocating that using CBC with intentional potential IV reuse is good security. But defense in depth is a good security practice and using primitives that fail less catastrophically when inevitable disasters happen is also a good security practice.
This is doubly so because there we know that that some sophisticated attackers have been known to exploit the brittleness of otherwise secure schemes to compromise implementations. Brittleness doesn't just increase exposure to chance it also makes it easier to inject bugdoors and to plausibly deny them.
Comparing GCM to CBC+HMAC is not fruitful because they are different in too many aspects. I already stated in the very first message in this thread that HMAC is far more robust than GMAC. Compare CTR+HMAC vs CBC+HMAC.
What I take issue with is people stating that CBC somehow provides more security than CTR mode under IV reuse. (Ie your statement that it provides defence in depth). That is a statement that doesn’t stand up to scrutiny in any rigorous way. Both fail pretty badly. Learning the XOR of two plaintexts is sometimes worse than learning if they share a common prefix, sometimes not.
Put it another way, how would using CBC vs CTR mode in any way impact your response to learning you had a IV reuse bug in production? It wouldn’t in any meaningful way at all - you’d still have to assume that the data was compromised to some degree. Compare that to a real defence in depth like SIV mode, where in most cases (not all) you could assume that no data breach occurred.
Thomas Ptacek thinks that I’m being a purist about this stuff. Fair enough. But I think people who believe that CBC provides meaningfully better protection than CTR in the real world are kidding themselves.
You're responding to an argument I didn't make. Obviously I don't believe that repeated CBC IVs are never an exploitable vulnerability. There are famously exploitable instances; one broke TLS. I'm arguing that a repeated CBC IV is less likely to be practically exploitable than a repeated CTR nonce, which is virtually always exploitable.
You previously said CTR mode nonce repetitions are “always bad” and are “game-over”. I provided a simple counterexample.
You also said that IV reuse in CBC mode can only be exploited if you setup an ECB-style attack. Also untrue.
Now you have retreated to merely claiming that CBC issues are less likely to be exploitable, but have provided absolutely zero evidence to backup that assertion. I don’t think you could really stand that up without making a bunch of assumptions about typical application data that I think are shaky.
The way to address this is not to endlessly debate the pros and cons of different confidentiality-only cipher modes. Instead, modern crypto acknowledges that none of them are CPA-secure in the case of IV reuse, and they all leak info in different ways. The best course of action is then to assume that in the worst case they are basically all terrible and design around that at higher levels: like SIV, or XChaCha, or whatever.
I didn't catch the CTR bit in your key wrap example. To be honest, when people start talking about key wrapping, I stop paying attention.
We just disagree. You have a purer take on this stuff. My personal experience, which is that of a vulnerability researcher and not that of a cryptography engineer, is that the purity test perspective is helpful for spotting patterns of vulnerability, but that's about it. It's demonstrably safer to run a CBC+HMAC authenticated secure channel than to run a GCM secure channel, and lots of people do exactly that for exactly that reason. The purity test vantage says "feh! the same bug exists in both!". The vulnerability researcher vantage says "no, all bugs are not in fact the same".
