undefined | Better HN

0 pointsDiggsey5y ago0 comments

Many of the alternative modes are unsuitable for this case, as it is being used to encrypt UDP packets which may be lost. There are two commonly used modes which support the random access needed here:

- ECB - CTR

Note that CTR is still recommended for use and is often used for things like hard-disk encryption where random access is required. Furthermore, the only difference between ECB and CTR is that CTR includes an incrementing counter in the input to the encryption algorithm to ensure that each encryption is unique. Do you know what else starts with an incrementing counter? UDP packets intended to form an audio or video stream.

So yes: ECB can be bad, but there's no evidence that Zoom are actually using it incorrectly. Using CTR when you already have a non-repeating data stream would only add overhead and potentially negatively impact the amount of useful data that can be streamed.

0 comments

hiq5y ago

Is there a way to use ECB "correctly"?

Is there any non-repeating data apart from noise (if even)?

DiggseyOP5y ago

Yes, as I mentioned, if you include an incrementing counter within each block then the data does not repeat. The data only needs to be non-repeating within a single stream. Different streams will use a different IV and possibly different keys. This is how CTR works.

katzenjam5y ago

Including a counter in each UDP packet does not make ECB mode equivalent to CTR mode.

Let's assume the counter is at the start of the packet. An AES block is 16 bytes, so the counter ensures the first 16 bytes of ciphertext are unique across packets. But any patterns in the remainder of the packet are preserved, within and across packets.

j / k navigate · click thread line to collapse