2 ms·
Thank you for clearly articulating why using AES-ECB here is not as bad as the penguin image everyone seems to know. It's still a bad choice - you really need t
by rzimmerman 7y ago
Thank you for clearly articulating why using AES-ECB here is not as bad as the penguin image everyone seems to know. It's still a bad choice - you really need to prove to yourself that your data stream isn't susceptible and it's honestly easier just to use an appropriate stream cipher mode.
I absolutely agree that the real deserved flak is for saying "end-to-end encryption" when that's clearly not what's happening. Honestly, I don't know how they could make their product work as well as it does with actual end-to-end (consumer to consumer) encryption. Self-hosted solutions can do this but their servers are doing a lot more than ferrying raw data streams around. That's why their meetings work so well with 200+ participants.
They also deserve criticism for saying AES-256 when they're using 128-bit keys, but like you said it's not a security issue. I suppose they could be referring to TLS that they use to set up connections and meetings rather than the stream itself but that's a stretch.
- akimball 7y agoWhen you control the content of the stream, you control whether there are repeated blocks. If there are none, do any objections to ECB remain?
- tptacek 7y agoYes: ECB is also somewhat malleable, and uniquely vulnerable to "cut-and-paste" attacks since nothing ties a run of ciphertext blocks to its position in the stream. But these arguably aren't especially relevant to Zoom's threat model.