4 ms·

Related to gotcha #1 - it also means that you have to have the entire message available when you start encryption. Lightweight embedded systems may not be able

Related to gotcha #1 - it also means that you have to have the entire message available when you start encryption. Lightweight embedded systems may not be able to meet that requirement.

olliej 8y ago
the problem with gcm’s nonce reuse weakness is that the best way to generate a unique nonce is as a hash of the input message - otherwise you technically have to record every nonce you’ve ever used. I guess an alternative would be to have a secret key and a counter and then have the nonce be something like aes(key, counter++) but obviously that has scalability issues I’m sure @tqpf/@tqbf (I cant recall) has opinions :)
- metalliqaz 8y ago
  Counters are already used in the generation of the keystream
- admax88q 8y ago
  > the best way to generate a unique nonce is as a hash of the input message - otherwise you technically have to record every nonce you’ve ever used. That doesn't sound right. I would wager that using a cryptographically secure RNG is less likely to produce the same number twice, or at the very least equally as likely. If you have a very strong hash, then the hash algorithm should act the same as an RNG.
  - metalliqaz 8y ago
    You are supposed to combine the hash with the user-provided nonce. It's not purely a hash, that's not good enough. The purpose is to protect against the user-provided nonce being weak. Still expect a proper nonce if it can be done.
  - olliej 8y ago
    The problem with gcm is that you absolutely cannot ever reuse a nonce, hence gcm-siv using a hash of the message - assuming a cryptographically strong hash the hash collision rate should theoretically have lower odds than a pure ring (sqrt(hashsize) vs likelihood of non-random different data colliding in practice) Of course all of this is on the assumption that any hashes and rngs you use are secure :) In practice: many sites using gcm were using rng based nonces that end up colliding
    - admax88q 8y ago
      I get why 'SIV' used a hash of the message in addition to the user provided nonce. My point was I disagree on your sentence "the best way to generate a unique nonce is as a hash of the input message - otherwise you technically have to record every nonce you’ve ever used." That implies that a hash is strong enough that you don't need to track messages. If you believe that to be the case then a CSRNG would be equally as strong of not stronger and less complex. Still sqrt(n) chance of collision.
- colmmacc 8y ago
  Nonces don't need to be secret. You can just use a counter value if you want, unencrypted. It gets harder when you have many uncoordinated senders. You can shard your nonce-space; give each sender a unique prefix, but this reduces the number of messages they can each send with the same key. Bigger services, such as Public Cloud providers (I work at AWS, and it's a factor for us) actually end up running up on these limits.
- darkr 8y ago
  The nonce shouldn’t be regarded as secret. Typically you’d generate a random nonce per encrypt action and pack it within the first few bytes of the output
shinigami 8y ago
For that you need to divide the message in chunks and encrypt&authenticate each chunk. It's what GPG is going to do soon. There are some ad-hoc approaches for that procedure, but two interesting and well-constructed are STREAM and CHAIN: https://eprint.iacr.org/2015/189.pdf https://eprint.iacr.org/2015/189.pdf

Related to gotcha #1 - it also means that you have to have the entire message available when you start encryption. Lightweight embedded systems may not be able to meet that requirement.

olliej 8y ago

the problem with gcm’s nonce reuse weakness is that the best way to generate a unique nonce is as a hash of the input message - otherwise you technically have to record every nonce you’ve ever used. I guess an alternative would be to have a secret key and a counter and then have the nonce be something like aes(key, counter++) but obviously that has scalability issues I’m sure @tqpf/@tqbf (I cant recall) has opinions :)

metalliqaz 8y ago
Counters are already used in the generation of the keystream
admax88q 8y ago
> the best way to generate a unique nonce is as a hash of the input message - otherwise you technically have to record every nonce you’ve ever used. That doesn't sound right. I would wager that using a cryptographically secure RNG is less likely to produce the same number twice, or at the very least equally as likely. If you have a very strong hash, then the hash algorithm should act the same as an RNG.
- metalliqaz 8y ago
  You are supposed to combine the hash with the user-provided nonce. It's not purely a hash, that's not good enough. The purpose is to protect against the user-provided nonce being weak. Still expect a proper nonce if it can be done.
- olliej 8y ago
  The problem with gcm is that you absolutely cannot ever reuse a nonce, hence gcm-siv using a hash of the message - assuming a cryptographically strong hash the hash collision rate should theoretically have lower odds than a pure ring (sqrt(hashsize) vs likelihood of non-random different data colliding in practice) Of course all of this is on the assumption that any hashes and rngs you use are secure :) In practice: many sites using gcm were using rng based nonces that end up colliding
  - admax88q 8y ago
    I get why 'SIV' used a hash of the message in addition to the user provided nonce. My point was I disagree on your sentence "the best way to generate a unique nonce is as a hash of the input message - otherwise you technically have to record every nonce you’ve ever used." That implies that a hash is strong enough that you don't need to track messages. If you believe that to be the case then a CSRNG would be equally as strong of not stronger and less complex. Still sqrt(n) chance of collision.
colmmacc 8y ago
Nonces don't need to be secret. You can just use a counter value if you want, unencrypted. It gets harder when you have many uncoordinated senders. You can shard your nonce-space; give each sender a unique prefix, but this reduces the number of messages they can each send with the same key. Bigger services, such as Public Cloud providers (I work at AWS, and it's a factor for us) actually end up running up on these limits.
darkr 8y ago
The nonce shouldn’t be regarded as secret. Typically you’d generate a random nonce per encrypt action and pack it within the first few bytes of the output

shinigami 8y ago

For that you need to divide the message in chunks and encrypt&authenticate each chunk. It's what GPG is going to do soon. There are some ad-hoc approaches for that procedure, but two interesting and well-constructed are STREAM and CHAIN: https://eprint.iacr.org/2015/189.pdf https://eprint.iacr.org/2015/189.pdf