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