0
$\begingroup$

In light of current events (Zoom getting strong headwinds for using AES-128 in ECB mode), I was wondering what the general approach is to packetized data encryption, where the packet length (UDP for video over internet: > 1200 B payload)

  1. Is it really just a block cipher in ECB mode, so that each packet can be decoded without any prior packet⁰?
  2. Is it a block cipher in some non-ECB mode, but it gets reset at the start of a packet?
  3. Is it a block cipher in some non-ECB mode, but we're just using a sufficiently large number of say $N$ different keys, de- and encoder, which we use in interleaved / sequential fashion, so that any erasure of less than $N$ successive packets gives us enough time to let the transmitter know we need to re-initialize the receiver?¹
  4. Would you go the WiFi/WPA route of deriving a key for each packet, leading to the couple of attacks we know against that TKIP/KDF method?
  5. Am I totally missing everything?

I've tried to look into how KASUMI (3G crypto standard) does this, but I haven't been able to track down the relevant standards document.


⁰ ... and everyone is bashing Zoom for adhering to industry best practice?

¹ wouldn't that lead to feasibility of forcing the encoder to a known state by an attacker with control over which packets get lost?

$\endgroup$
  • $\begingroup$ I'm assuming that the receiver will know which packets are missing? (plain sequence numbers or something) If that's the case, CTR mode or any other stream cipher would work without any problems by just skipping part of the keystream. $\endgroup$ – Maeher Apr 4 at 11:23
  • $\begingroup$ Format the header and the data payload properly and apply a well-designed AEAD cipher is the best current practice that some people fail to do. $\endgroup$ – DannyNiu Apr 4 at 11:23
  • $\begingroup$ @Maeher yep, a sequence number can be assumed to be present; had to look up CTR mode, ah, yeah, that makes a lot of sense. $\endgroup$ – Marcus Müller Apr 4 at 11:27
  • $\begingroup$ @DannyNiu um, picture me confused: I'm asking "what (or how) is a well-designed cipher mode for this scheme?" and you answer by "just use a well-designed cipher!"; am I missing something? $\endgroup$ – Marcus Müller Apr 4 at 11:28
  • $\begingroup$ @MarcusMüller It's not just any well-designed cipher. A properly designed AEAD cipher protects the confidentiality of the data payload as well as the authenticity of the data and the header. In this way, AEAD provides an "interface" to the application to detect a wide range of passive and active attacks. $\endgroup$ – DannyNiu Apr 4 at 11:30
1
$\begingroup$

Is it really just a block cipher in ECB mode, so that each packet can be decoded without any prior packet⁰?

No. ECB is bad and creating a secure real-time channel (that can even handle packet loss) is a solved problem. It has been for years. There's no good excuse for using ECB here.

Is it a block cipher in some non-ECB mode, but it gets reset at the start of a packet?

The usual approach would be to have some form of initialization vector for the encryption which is sent as cleartext with every packet and is used to re-synchronize the state between both endpoints if packet loss is expected. For some encryption schemes this can simply be the packet counter. Then once you have synchronized state for a packet, you use a stateful encryption scheme, like GCM or CTR + HMAC to encrypt the singular packet.

If you want to have a look at how this works out in practice, the three big secure channel standards are TLS (cannot handle lossy underlying layer), DTLS (adaption of TLS 1.2 for lossy contexts) and SRTP.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Nice! Wasn't aware of DTLS nor SRTP. $\endgroup$ – Marcus Müller Apr 4 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.