4 ms·

But it’s less bad because of HMAC, not because of CBC. Hand waving arguments that CBC is meaningfully better than CTR mode under IV reuse are silly. There are c

But it’s less bad because of HMAC, not because of CBC. Hand waving arguments that CBC is meaningfully better than CTR mode under IV reuse are silly. There are cases where a nonce reuse in CTR mode reveals very little (eg key wrapping) and cases where the same in CBC mode reveals everything. The worst case for both is equally bad.

tptacek 3y ago
I still disagree with you even given this refinement. A repeated CBC IV is a second-order vulnerability that still requires you to set up the conditions for an ECB-style attack on the system, which isn't always possible. A repeated CTR nonce immediately sacrifices confidentiality.
- nmadden 3y ago
  That’s not true. CBC mode with a repeated IV immediately reveals equality of plaintexts or any common prefix (modulo block size).
  - tptacek 3y ago
    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.
    - nmadden 3y ago
      > 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. [1]: https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-library-if-you-absolutely-must/ https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...
      - tptacek 3y ago
        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.
        nmadden 3y ago
        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.
        tptacek 3y ago
        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". It's fine that we disagree.
      - nullc 3y ago

tptacek 3y ago

I still disagree with you even given this refinement. A repeated CBC IV is a second-order vulnerability that still requires you to set up the conditions for an ECB-style attack on the system, which isn't always possible. A repeated CTR nonce immediately sacrifices confidentiality.

nmadden 3y ago
That’s not true. CBC mode with a repeated IV immediately reveals equality of plaintexts or any common prefix (modulo block size).
- tptacek 3y ago
  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.
  - nmadden 3y ago
    > 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. [1]: https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-library-if-you-absolutely-must/ https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...
    - tptacek 3y ago
      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.
      - nmadden 3y ago
        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.
        tptacek 3y ago
        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". It's fine that we disagree.
    - nullc 3y ago