3 ms·

I think it's easier than that. When using the IV using a 96 bit fixed field and 32 bit counter, FIPS SP800-38d says you are limited to 2**32 "invocations of the

by fargle 3y ago

I think it's easier than that. When using the IV using a 96 bit fixed field and 32 bit counter, FIPS SP800-38d says you are limited to 2**32 "invocations of the authenticated encryption function with any given fixed field and key". What they call the fixed field is the common 96 bit IV or nonce. So you can do 512Gb or 64GB under one nonce. Then simply increment the fixed field and run the next 64GB under the same key and new nonce (nonce+1) and so on. In essence, it's the same thing is just making the fixed field smaller and the counter bigger, but meets the letter and intent of the law. The "fixed field" can be anything the user wants, including being "constructed from two or more smaller fields". And it is not constrained to remain the same under multiple invocations. Still compatible with FIPS and common implementations. It doesn't have to be some fancy ratcheting scheme. The initial "fixed field" or nonce could even always just be all zeros [1]. It doesn't matter, it's not secret. If for some reason you want to encrypt that much under one key, which I think you really don't. 1: well, in most cases especially AES-256: https://crypto.stackexchange.com/questions/68774/can-a-zero-nonce-be-safely-used-with-aes-gcm-if-the-key-is-random-and-never-used https://crypto.stackexchange.com/questions/68774/can-a-zero-...

tptacek 3y ago
The problem with this is that if the nonce ever collides under the same key, GCM's security falls to pieces, and so if you're using the nonce as an extended counter --- a thing people do, in part because they're worried 96 bits is too short to safely choose randomly --- you have to design a system that can't use the nonce "0" (or "1" or "2") twice. If all your keys are ephemeral this isn't a big worry, but if they aren't, you can end up talking about reliably keeping state between invocations of your whole program. (Apologies if this is obvious!)
- cyberax 3y ago
  > GCM's security falls to pieces That's an exaggeration. Reusing the nonce in GCM allows decryption of messages with the same nonce. It does NOT compromise the key.
  - idorosen 3y ago
    Allowing decryption of the messages sounds like falling to pieces to me...
    - cyberax 3y ago
      Messages with duplicate nonces. Recovery of the authentication key may also allow message forgery (although it won't allow decryption).
      - nmadden 3y ago
        Message forgery does quite often lead to decryption actually - google “chosen ciphertext attack”.
        cyberax 3y ago
        None of the modern symmetric ciphers are susceptible to chosen ciphertext attacks.
        nmadden 3y ago
        Say what now? GCM is itself vulnerable to CCA in a nonce reuse scenario - exactly the subject of this thread. Not to mention padding oracle attacks against CBC mode etc. Almost all modern symmetric ciphers achieve CCA security by combining the cipher with a MAC to create an AEAD mode. So if your AEAD mode gives up the MAC subkey, as GCM does under nonce reuse, then you lose all CCA security, and usually starting leaking details about plaintexts not long after.
        cyberax 3y ago
        Sigh. If you're talking about crypto, then terms actually matter. GCM is not a symmetric cipher. It's a cipher mode. You can use GCM with any block cipher. OK, I assume that you meant AES-GCM. But GCM as a construction in itself is not vulnerable to chosen ciphertext attacks, as long as the underlying symmetric cipher is secure. GCM will lose the authentication property, if you know the authentication key, which you _might_ be able to get if you can mount a chosen _plaintext_ attack under conditions of nonce reuse. Simply getting a couple of random messages with the same nonce is NOT enough. AES-GCM as specified has a nonce that is large enough to not care about it in practical cases (e.g. TLS), and it can become a problem only in very unrealistic cases (attacker-controlled likely exabyte-sized plaintexts). These cases are maybe _juuuust_ in the realm of possibility, if you have access to a supercomputer, and you want to specifically design an application that is vulnerable to an attack, and then allow your adversary to covertly connect to your supercomputer cluster. To be clear, we're talking here about repurposing the entire NSA computing and storage power to host this single application, and allowing the attacker (e.g. Russian troll farms) to completely control the plaintexts that it transmits. Extending the nonce to 256 bits would move that from outside the realm of possibility even for a contrived scenario. It's not a bad idea, but it's also not at all an urgent one.
- fargle 3y ago
  > you have to design a system that can't use the nonce "0" (or "1" or "2") twice. just like any counter mode. it's vitally important, but not difficult to understand or implement. the other point is, WHY NOT JUST ROLL THE KEY MORE OFTEN. nobody should be encrypting 64GB under the same key. and 96+256 is enough bits that can be chosen randomly to never worry about collisions.
  - tptacek 3y ago
    This bit about it not being difficult to implement is false. The single most damaging vulnerability class of the last 25 years came from the inability of programmers to reliably count bytes. It's simple to come up with something that works reliably without the presence of an adversary. But as soon as you add an adversary who will manipulate inputs and environments to put you into corner cases, counting becomes quite difficult indeed, no matter how simple you think it is to understand counting. If you create the opportunity to make a mistake remembering to freshen a nonce, even if that opportunity is remote, such that you'd never trip over it accidentally, you've given attackers a window to elaborately synthesize that accident for you. That's what a vulnerability is. There is a whole subfield of cryptography right now dedicated to "nonce misuse resistance", motivated entirely by this one problem. This is what I love about cryptography. You could go your entire career in the rest of software security and not come up with a single new bug class (just instances of bug patterns that people have been finding for years). But cryptography has them growing on trees, and it is early days for figuring out how to weaponize them. That's why people pay so much attention to stuff like nonce widths.

by fargle 3y ago

tptacek 3y ago

The problem with this is that if the nonce ever collides under the same key, GCM's security falls to pieces, and so if you're using the nonce as an extended counter --- a thing people do, in part because they're worried 96 bits is too short to safely choose randomly --- you have to design a system that can't use the nonce "0" (or "1" or "2") twice. If all your keys are ephemeral this isn't a big worry, but if they aren't, you can end up talking about reliably keeping state between invocations of your whole program. (Apologies if this is obvious!)

cyberax 3y ago
> GCM's security falls to pieces That's an exaggeration. Reusing the nonce in GCM allows decryption of messages with the same nonce. It does NOT compromise the key.
- idorosen 3y ago
  Allowing decryption of the messages sounds like falling to pieces to me...
  - cyberax 3y ago
    Messages with duplicate nonces. Recovery of the authentication key may also allow message forgery (although it won't allow decryption).
    - nmadden 3y ago
      Message forgery does quite often lead to decryption actually - google “chosen ciphertext attack”.
      - cyberax 3y ago
        None of the modern symmetric ciphers are susceptible to chosen ciphertext attacks.
        nmadden 3y ago
        Say what now? GCM is itself vulnerable to CCA in a nonce reuse scenario - exactly the subject of this thread. Not to mention padding oracle attacks against CBC mode etc. Almost all modern symmetric ciphers achieve CCA security by combining the cipher with a MAC to create an AEAD mode. So if your AEAD mode gives up the MAC subkey, as GCM does under nonce reuse, then you lose all CCA security, and usually starting leaking details about plaintexts not long after.
        cyberax 3y ago
        Sigh. If you're talking about crypto, then terms actually matter. GCM is not a symmetric cipher. It's a cipher mode. You can use GCM with any block cipher. OK, I assume that you meant AES-GCM. But GCM as a construction in itself is not vulnerable to chosen ciphertext attacks, as long as the underlying symmetric cipher is secure. GCM will lose the authentication property, if you know the authentication key, which you _might_ be able to get if you can mount a chosen _plaintext_ attack under conditions of nonce reuse. Simply getting a couple of random messages with the same nonce is NOT enough. AES-GCM as specified has a nonce that is large enough to not care about it in practical cases (e.g. TLS), and it can become a problem only in very unrealistic cases (attacker-controlled likely exabyte-sized plaintexts). These cases are maybe _juuuust_ in the realm of possibility, if you have access to a supercomputer, and you want to specifically design an application that is vulnerable to an attack, and then allow your adversary to covertly connect to your supercomputer cluster. To be clear, we're talking here about repurposing the entire NSA computing and storage power to host this single application, and allowing the attacker (e.g. Russian troll farms) to completely control the plaintexts that it transmits. Extending the nonce to 256 bits would move that from outside the realm of possibility even for a contrived scenario. It's not a bad idea, but it's also not at all an urgent one.
fargle 3y ago
> you have to design a system that can't use the nonce "0" (or "1" or "2") twice. just like any counter mode. it's vitally important, but not difficult to understand or implement. the other point is, WHY NOT JUST ROLL THE KEY MORE OFTEN. nobody should be encrypting 64GB under the same key. and 96+256 is enough bits that can be chosen randomly to never worry about collisions.
- tptacek 3y ago
  This bit about it not being difficult to implement is false. The single most damaging vulnerability class of the last 25 years came from the inability of programmers to reliably count bytes. It's simple to come up with something that works reliably without the presence of an adversary. But as soon as you add an adversary who will manipulate inputs and environments to put you into corner cases, counting becomes quite difficult indeed, no matter how simple you think it is to understand counting. If you create the opportunity to make a mistake remembering to freshen a nonce, even if that opportunity is remote, such that you'd never trip over it accidentally, you've given attackers a window to elaborately synthesize that accident for you. That's what a vulnerability is. There is a whole subfield of cryptography right now dedicated to "nonce misuse resistance", motivated entirely by this one problem. This is what I love about cryptography. You could go your entire career in the rest of software security and not come up with a single new bug class (just instances of bug patterns that people have been finding for years). But cryptography has them growing on trees, and it is early days for figuring out how to weaponize them. That's why people pay so much attention to stuff like nonce widths.