3 ms·

Why can't people bother to construct a minimally secure encryption system given that there are so many good documents and code examples out there? I don't mean

by api 7y ago

Why can't people bother to construct a minimally secure encryption system given that there are so many good documents and code examples out there? I don't mean anything with ratcheting, forward secrecy, replay protection, nonce reuse resistance, or any other bells and whistles, just basic competent symmetric encryption without gaping holes or ridiculous bizarre design choices? It's not hard! (1) Generate 12 bytes of random nonce using a good secure random source, prepend to message. (2) Use nonce to initialize AES-GCM. (3) Run it through AES-GCM, append tag. (4) Done. That's not hard and it's secure enough for common use cases.

rzimmerman 7y ago
The only thing I can think if is that maybe the protocol Zoom is using precludes prepending the nonce due to the packet format. But surely there's some way to do this with packet counters and user IDs. It's possible this was an intermediate step but I'm really stretching for excuses here.
- api 7y ago
  Yes you can construct an IV from other state, though it's not ideal. Another good fit might be modes designed for disk encryption as those are designed for cases where you can't pad (e.g. disk blocks). There's also AES-GCM-SIV and its relatives which construct the nonce from a MAC of the plaintext and technically do not require a separate IV, though if you don't use one any duplicate message will be obvious. Those are somewhat more complex but honestly even if you don't get those perfect it's almost definitely better than ECB.
restingrobot 7y ago
Or use TLS end to end like a normal company...
- api 7y ago
  Yeah I wasn't saying that because it's obvious. I was just saying if you really want to DIY crypto it's not that hard to do better than dumb ECB.
unscaled 7y ago
No, that doesn't solve the problem at all! AES-GCM was not designed to be used with random nonces - otherwise the nonce space would need to be larger than 96 bits. It was only designed to be safe with a unique counter nonce. That does not always become a problem, but it will in Zoom's case. Zoom is encrypting a video stream, which means you cannot use AES-GCM wholesale, but have to use it to encrypt chunks of data. The problem is that 12 bytes (96 bits) of nonce is just not enough, and after encrypting a certain amount of data with the same key, the chance of repeating the nonce becomes rather high. And if you have a long video conference call with many participants using the same key, you'll sooner or later generate enough data that the nonce will be repeated. Once the nonce is repeated, GCM loses its security guarantees. It's hard for me to estimate how bad it would be, since I'm not familiar enough with the plaintext data characteristics, but in this case it could even be worse than using ECB. AES-GCM is a cryptographic primitive that is meant for sequential whole-message encryption. The moment you're using it for streaming you are rolling your own crypto. Even if you've used a cipher that supports larger nonces like XChaCha20-Poly1305, you can still not be sure that you're absolutely free from mistakes if you also want authentication, for instance. Zoom was negligent for just going ahead with AES-ECB, but finding a solution for this problem is not that simple. When you need to stream encrypted data, encrypting it directly with a safe AEAD construction is not always going to make you safe. That's why it's generally safer to use TLS, even considering how historically problematic TLS is. Of course Zoom could not use TLS for streaming video, since this would preclude them from using UDP and allowing for packet loss. I've never encrypted TLS traffic and I'm not familiar enough with other protocols like dTLS and [Noise](https://noiseprotocol.org/ https://noiseprotocol.org/) to know if they will be useful in this case, so I won't be making any claims to how easy this is.

by api 7y ago

rzimmerman 7y ago

The only thing I can think if is that maybe the protocol Zoom is using precludes prepending the nonce due to the packet format. But surely there's some way to do this with packet counters and user IDs. It's possible this was an intermediate step but I'm really stretching for excuses here.

api 7y ago
Yes you can construct an IV from other state, though it's not ideal. Another good fit might be modes designed for disk encryption as those are designed for cases where you can't pad (e.g. disk blocks). There's also AES-GCM-SIV and its relatives which construct the nonce from a MAC of the plaintext and technically do not require a separate IV, though if you don't use one any duplicate message will be obvious. Those are somewhat more complex but honestly even if you don't get those perfect it's almost definitely better than ECB.

restingrobot 7y ago

Or use TLS end to end like a normal company...

api 7y ago
Yeah I wasn't saying that because it's obvious. I was just saying if you really want to DIY crypto it's not that hard to do better than dumb ECB.

unscaled 7y ago

No, that doesn't solve the problem at all! AES-GCM was not designed to be used with random nonces - otherwise the nonce space would need to be larger than 96 bits. It was only designed to be safe with a unique counter nonce. That does not always become a problem, but it will in Zoom's case. Zoom is encrypting a video stream, which means you cannot use AES-GCM wholesale, but have to use it to encrypt chunks of data. The problem is that 12 bytes (96 bits) of nonce is just not enough, and after encrypting a certain amount of data with the same key, the chance of repeating the nonce becomes rather high. And if you have a long video conference call with many participants using the same key, you'll sooner or later generate enough data that the nonce will be repeated. Once the nonce is repeated, GCM loses its security guarantees. It's hard for me to estimate how bad it would be, since I'm not familiar enough with the plaintext data characteristics, but in this case it could even be worse than using ECB. AES-GCM is a cryptographic primitive that is meant for sequential whole-message encryption. The moment you're using it for streaming you are rolling your own crypto. Even if you've used a cipher that supports larger nonces like XChaCha20-Poly1305, you can still not be sure that you're absolutely free from mistakes if you also want authentication, for instance. Zoom was negligent for just going ahead with AES-ECB, but finding a solution for this problem is not that simple. When you need to stream encrypted data, encrypting it directly with a safe AEAD construction is not always going to make you safe. That's why it's generally safer to use TLS, even considering how historically problematic TLS is. Of course Zoom could not use TLS for streaming video, since this would preclude them from using UDP and allowing for packet loss. I've never encrypted TLS traffic and I'm not familiar enough with other protocols like dTLS and [Noise](https://noiseprotocol.org/ https://noiseprotocol.org/) to know if they will be useful in this case, so I won't be making any claims to how easy this is.