4 ms·

You're entitled to your thing. Granted, CBC mode has a better misuse story than CTR, but an extended-nonce ChaPoly AEAD is likely to be safer in most of Signal'

You're entitled to your thing. Granted, CBC mode has a better misuse story than CTR, but an extended-nonce ChaPoly AEAD is likely to be safer in most of Signal's installed userbase (n.b. the same userbase Matrix and Jitsi would be targeting in a lot of cases), given the ARM SIMD (AES-NI equivalent) situation.

tptacek 6y ago
Chapoly depends on a reliable per-message CSPRNG. CBC wants randomness too, of course, but the failure mode under randomness hiccups isn't "coughs up keys". If you have a system working with CBC+HMAC, what's the advantage to shouldering that additional risk? In a new design, I'd recommend Chapoly too. But this isn't a new design. Changing things has cost.
- CiPHPerCoder 6y ago
  > If you have a system working with CBC+HMAC, what's the advantage to shouldering that additional risk? The details you probably want me to put here are a bit fuzzy still, and I've solicited others' to provide clarity and insight into the specifics, so I apologize if this is hand-wavy, but your question deserves an answer. Given: Most smartphones are built on ARM architecture. At the very least, I'm confident about Android being ARM. I've never purchased an Apple product in my life, and can't rightly say much about their internals. ARM before ARMv8-A did not provide hardware AES. https://en.wikipedia.org/wiki/ARM_architecture#ARMv8-A https://en.wikipedia.org/wiki/ARM_architecture#ARMv8-A Adiantum cites the Cortex-A7 as one example processor that does not provide hardware-accelerated AES: https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html https://security.googleblog.com/2019/02/introducing-adiantum... "In order to offer low cost options, device manufacturers sometimes use low-end processors such as the ARM Cortex-A7, which does not have hardware support for AES. On these devices, AES is so slow that it would result in a poor user experience; apps would take much longer to launch, and the device would generally feel much slower." Even for smartphones that use ARMv8-A and newer, OEM weirdness can get in the way of that. Without tearing a specific model of a specific phone apart, I can't really give you much more information than that. The advantage to the additional risk of ChaPoly is to not cough up keys to JavaScript running in a web browser capable of leveraging a cache-timing attack against software AES, in the smartphones that most people can afford. That is to say, while it's true that the CSPRNG failure mode of ChaPoly is bad (but relies on conditions the attacker probably can't control), the failure mode of software AES is equally bad and can be influenced by an attacker. > In a new design, I'd recommend Chapoly too. But this isn't a new design. Changing things has cost. If there is significant market share where the device has a reliable CSPRNG but not hardware AES (post-OEM tampering), I'd argue that the security gain of a ChaPoly migration is worth the cost of changing, in particular. The ratcheting changes are mostly a hygiene issue and probably won't be meaningfully important. I was just being nitpicky.
  - tptacek 6y ago
    If it's running in a web browser, side-channel attacks are way down the list of problems you need to account for.
    - CiPHPerCoder 6y ago
      I think you misunderstood what I'm talking about here. [ App (Java -> Dvorak) ]--. >--- Same CPU [ Web Browser with JS ]--` My argument wasn't about "it" running in a web browser. I was arguing that side-channel attacks that can be exploited from a browser on the same CPU (as per djb's AES cache attack paper) are pretty bad, considering "trick user into opening a webpage" is a pretty low-hanging fruit attack vector.
- dependenttypes 6y ago
  > Chapoly depends on a reliable per-message CSPRNG What? You just need the CSPRNG for generating the initial nonce (to use with the shared secret). You can just use a counter for different messages.
  - tptacek 6y ago
    If you're doing that, you're not using extended-nonce ChaCha. The counter, of course, is often even more fraught.
    - dependenttypes 6y ago
      > If you're doing that, you're not using extended-nonce ChaCha This is not the case at all.

tptacek 6y ago

Chapoly depends on a reliable per-message CSPRNG. CBC wants randomness too, of course, but the failure mode under randomness hiccups isn't "coughs up keys". If you have a system working with CBC+HMAC, what's the advantage to shouldering that additional risk? In a new design, I'd recommend Chapoly too. But this isn't a new design. Changing things has cost.

CiPHPerCoder 6y ago
> If you have a system working with CBC+HMAC, what's the advantage to shouldering that additional risk? The details you probably want me to put here are a bit fuzzy still, and I've solicited others' to provide clarity and insight into the specifics, so I apologize if this is hand-wavy, but your question deserves an answer. Given: Most smartphones are built on ARM architecture. At the very least, I'm confident about Android being ARM. I've never purchased an Apple product in my life, and can't rightly say much about their internals. ARM before ARMv8-A did not provide hardware AES. https://en.wikipedia.org/wiki/ARM_architecture#ARMv8-A https://en.wikipedia.org/wiki/ARM_architecture#ARMv8-A Adiantum cites the Cortex-A7 as one example processor that does not provide hardware-accelerated AES: https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html https://security.googleblog.com/2019/02/introducing-adiantum... "In order to offer low cost options, device manufacturers sometimes use low-end processors such as the ARM Cortex-A7, which does not have hardware support for AES. On these devices, AES is so slow that it would result in a poor user experience; apps would take much longer to launch, and the device would generally feel much slower." Even for smartphones that use ARMv8-A and newer, OEM weirdness can get in the way of that. Without tearing a specific model of a specific phone apart, I can't really give you much more information than that. The advantage to the additional risk of ChaPoly is to not cough up keys to JavaScript running in a web browser capable of leveraging a cache-timing attack against software AES, in the smartphones that most people can afford. That is to say, while it's true that the CSPRNG failure mode of ChaPoly is bad (but relies on conditions the attacker probably can't control), the failure mode of software AES is equally bad and can be influenced by an attacker. > In a new design, I'd recommend Chapoly too. But this isn't a new design. Changing things has cost. If there is significant market share where the device has a reliable CSPRNG but not hardware AES (post-OEM tampering), I'd argue that the security gain of a ChaPoly migration is worth the cost of changing, in particular. The ratcheting changes are mostly a hygiene issue and probably won't be meaningfully important. I was just being nitpicky.
- tptacek 6y ago
  If it's running in a web browser, side-channel attacks are way down the list of problems you need to account for.
  - CiPHPerCoder 6y ago
    I think you misunderstood what I'm talking about here. [ App (Java -> Dvorak) ]--. >--- Same CPU [ Web Browser with JS ]--` My argument wasn't about "it" running in a web browser. I was arguing that side-channel attacks that can be exploited from a browser on the same CPU (as per djb's AES cache attack paper) are pretty bad, considering "trick user into opening a webpage" is a pretty low-hanging fruit attack vector.
dependenttypes 6y ago
> Chapoly depends on a reliable per-message CSPRNG What? You just need the CSPRNG for generating the initial nonce (to use with the shared secret). You can just use a counter for different messages.
- tptacek 6y ago
  If you're doing that, you're not using extended-nonce ChaCha. The counter, of course, is often even more fraught.
  - dependenttypes 6y ago
    > If you're doing that, you're not using extended-nonce ChaCha This is not the case at all.