4 ms·

I heard once that people didn't like the regularity of the input of CTR mode. That might be why people back in the day preferred CBC. These days, the big downs

by rocqua 9y ago

I heard once that people didn't like the regularity of the input of CTR mode. That might be why people back in the day preferred CBC. These days, the big downside to stream-ciphers is nonce-reuse. It can be hard to guarantee each message has a separate nonce on e.g. embedded platforms.

mehrdadn 9y ago
How can embedded platforms generate IVs but face trouble generating nonces? Aren't IVs also nonces? Or do you mean a different aspect of it is the problem?
- consp 9y ago
  In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random. Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations. There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
  - griffinmb 9y ago
    I think the issue is more that nonce reuse with stream ciphers like GCM result in a more catastrophic failure (i.e. secret key disclosure), whereas reusing the IV with CBC will only disclose whether some plaintext was encrypted multiple times. In an embedded platform where there is no easy way to ensure a nonce is not reused, the potential info disclosure may be preferable.
- tptacek 9y ago
  IVs aren't nonces. Nonces need to be unique. IVs need to be unpredictable. Those are subtly different requirements.
- mschwaig 9y ago
  Both is an about euqally difficult problem, but modes that require a nonce fail much more spectacularly than modes that require an IV. Typically with a re-used IV the same plain text will lead to the same cipher text, which can be an issue. On the other hand with a re-used nonce you can basically recover the xor of two plain texts from two cipher texts. This leads to plain text very quickly and is a much more serious issue.

by rocqua 9y ago

mehrdadn 9y ago

How can embedded platforms generate IVs but face trouble generating nonces? Aren't IVs also nonces? Or do you mean a different aspect of it is the problem?

consp 9y ago
In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random. Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations. There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
- griffinmb 9y ago
  I think the issue is more that nonce reuse with stream ciphers like GCM result in a more catastrophic failure (i.e. secret key disclosure), whereas reusing the IV with CBC will only disclose whether some plaintext was encrypted multiple times. In an embedded platform where there is no easy way to ensure a nonce is not reused, the potential info disclosure may be preferable.
tptacek 9y ago
IVs aren't nonces. Nonces need to be unique. IVs need to be unpredictable. Those are subtly different requirements.
mschwaig 9y ago
Both is an about euqally difficult problem, but modes that require a nonce fail much more spectacularly than modes that require an IV. Typically with a re-used IV the same plain text will lead to the same cipher text, which can be an issue. On the other hand with a re-used nonce you can basically recover the xor of two plain texts from two cipher texts. This leads to plain text very quickly and is a much more serious issue.