1
$\begingroup$

Stream ciphers are usually used for streaming data encryption, such as voice, and also for low layers data encryption. For example, MACSec uses AES-GCM encryption. In L3 ad L4 security protocols (IPSec and SSL) block ciphers are preferred (AES-CBC).

  1. Why are stream ciphers considered to be better than block ciphers in low layer encryption and block ciphers considered to be better for higher-level encryption?
  2. What makes voice data (which is application layer data) suitable for stream cipher? Isn't it easier to divide the voice stream into blocks and encrypt it with block cipher?
$\endgroup$
1
  • 3
    $\begingroup$ Note that AES is a block cipher and GCM ( internally CTR ) mode turns that into a stream cipher. The benefit of direct stream ciphers is the speed and usually, they have a small footprint in hardware. Apart from those, the selection is a bit historical. And TLS 1.3 uses AES-GCM, CCM, ChaCha20-Poly1305, too. Bot act as stream ciphers. $\endgroup$ – kelalaka Dec 21 '20 at 20:45
4
$\begingroup$

In L3 ad L4 security protocols (IPSec and SSL) block ciphers are preferred (AES-CBC).

Errr, no. Originally, SSL used RC4 (which is a stream cipher); then CBC mode (first DES/3DES and then AES) was added. In the latest version (TLS 1.3), they discarded RC4 and CBC mode entirely, in favor of AEAD modes (GCM and Chacha20/Poly1305).

As for IPsec, it was originally CBC mode only (first DES/3DES and then AES). Later, they added AEAD modes, and I believe they are currently the most common.

Hence, your claim that AES-CBC is preferred is not currently accurate, and so the assumptions behind your first question is not relevent.

Your section question is still interesting:

  1. What makes voice data (which is application layer data) suitable for stream cipher? Isn't it easier to divide the voice stream into blocks and encrypt it with block cipher?

With voice, they tend to be quite sensitive to encryption overhead; the VoIP packets themselves are quite tiny (circa 20 bytes on average, IIRC), and so a fixed amount of overhead would be a larger fraction of the total overhead than, say, in TLS. In addition, VoIP often goes over wireless, and they are especially sensitive to bandwidth there (in large part because of power; transmitting more bytes uses more power). What this means is that VoIP encryption protoocols (such as sRTP) are designed to minimize encryption overhead over just about any other consideration.

Hence, modes that require padding (such as AES-CBC) would be rejected outright, in favor of modes that don't (such as AES-CTR).

$\endgroup$
6
  • $\begingroup$ And, CCM in TLS 1.3. $\endgroup$ – kelalaka Dec 21 '20 at 21:03
  • 1
    $\begingroup$ @kelalaka: I know that two CCM-based ciphersuites are in TLS 1.3; does anyone actually use them? $\endgroup$ – poncho Dec 21 '20 at 21:05
  • $\begingroup$ Nice point, I don't know either. So what was the point of them to be included :) $\endgroup$ – kelalaka Dec 21 '20 at 21:05
  • $\begingroup$ AEAD modes (GCM, CCM, and ChaCha/Poly) were available in TLS1.2, but not required as they are in 1.3. Although many 1.2 implementations now prefer them. $\endgroup$ – dave_thompson_085 Dec 22 '20 at 2:22
  • $\begingroup$ Thanks for the detalied answers. I see that in many applications stream ciphers are common than block cipher - whether is Salsa20, AES-GCM, etc. In which cases would a stream cipher be preferred over a block cipher and vice versa? Also, why will we prefer to use a block cipher at all if we can use a stream cipher - which is faster, errors are not cumulative and doesn't require padding when the message has a different size than the block (like in ethernet encryption, where we have to pad the frame to multiplication of 16 if we want to use, for example, AES-CBC-128 block cipher)? $\endgroup$ – Dror123 Dec 22 '20 at 6:33
2
$\begingroup$
  1. Why are stream ciphers considered to be better than block ciphers in low layer encryption and block ciphers considered to be better for higher lever encryption?

Traditionally this seems to be the case, but is no longer necessarily true. TLS 1.3 uses ChaCha. On that note, ChaCha isn't any provably any less secure than AES.

  1. What makes voice data (which is application layer data) suitable for stream cipher? Isn't it easier to divide the voice stream into blocks and encrypt it with block cipher?

Using ChaCha as an example, we need to generate 512bits of key and we can then process byte-by-byte. With a block cipher we'd need to process the whole block. There would be added delay processing the voice into and out of the block.

Assuming no error correction - If there is an error of 1 bit, it affects one bit. With human ears we can't hear anything. Depending on block cipher mode we might end up garbling the whole block.

If the stream cipher is quicker (as is likely) then it is also an obvious benefit.

$\endgroup$
1
  • $\begingroup$ Technically TLS1.2 also can use ChaCha/Poly, see RFC7905. However, IME most stacks that implemented this also implemented 1.3, which of course is preferred over 1.2 when both are available. $\endgroup$ – dave_thompson_085 Dec 22 '20 at 2:20

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.