9
$\begingroup$

I can precompute the key stream for the CTR mode operation and the encryption at that point is similar to a stream cipher. So why are there stream ciphers still used and proposed after RC4? Recently the ChaCha20 as part of the ChaCha20-Poly1305 AE cipher.

Are there advantages to using a stream cipher especially?

Improve this question
$\endgroup$
13
$\begingroup$

AES-CTR is a stream cipher, of a particular kind where the keystream is obtained by encryption of a counter. So the question reduces to: what are drawbacks of AES-CTR compared to other stream ciphers?

The main ones compared to ChaCha20 are:

  1. Without hardware support, AES can fail to cache-timing attacks.
  2. Without hardware support, AES is slower.
  3. Without hardware support, the fastest implementations of AES use significant memory.
  4. Pre-computed AES subkeys (which speeds-up things) require not quite negligible memory (160 bytes for AES-128 in addition to the base key, compared to none for ChaCha20); this is an issue when many sessions each with a different key are active simultaneously.
  5. There's a theoretical distinguisher for AES after about $2^{68}$ bytes (but it requires as much memory, and wouldn't be much a practical issue anyway).

Compared to other modern stream ciphers like Trivium, AES requires more hardware at comparable speed. On the other hand it allows random access to the keystream, and parallelization (as ChaCha20 does), when many other stream ciphers (including Trivium and RC4) do not.

Bare AES-CTR does not provide authenticated encryption (AES-GCM does, and uses AES-CTR for encryption), so comparison to ChaCha20-Poly1305 is unfair.

Improve this answer
$\endgroup$
3
  • $\begingroup$ That is all I could think of too (faster than AES in software). Significantly lower memory usage is nice too. Thanks. $\endgroup$ – user220201 May 26 '15 at 21:07
  • $\begingroup$ Re. point 5 - distinguisher. Speculatively, would no distinguisher be possible if AES was a pseudo random function and not a permutation? $\endgroup$ – Paul Uszak Jun 8 '18 at 20:49
  • 1
    $\begingroup$ @PaulUszak That's correct. If a counter was fed into a keyed PRF instead of a PRP, it could be safely used right until the counter repeats. That's why ciphers like ChaCha20 can be used even with small counters. $\endgroup$ – forest Jan 28 '19 at 3:52
6
$\begingroup$

First, AES-CTR isn't "similar to a stream cipher." It is a stream cipher. That means the real question is "why do we develop new stream ciphers when AES-CTR provides an acceptable one?"

The answer is that newer stream ciphers tend to be superior to AES in some way or another. AES is a secure cipher, but it has some bad properties; for instance, it's hard and slowish to securely implement AES in software (the design works great if you're building dedicated hardware and OK for software, but the most natural software implementations are vulnerable to side-channel attacks). Salsa20 is designed for easy and highly efficient software implementation, with many fewer "gotchas" that lead to side-channel attacks.

Also, there are inherent advantages to having at least a few unrelated standard algorithms, because it reduces the impact of a break of one algorithm. If AES is the only cipher out there, and AES is broken, the results are catastrophic, because not only is lots of previously encrypted data at risk, but there isn't a widely accepted alternative. With multiple alternatives, if AES is broken it's still a huge deal, but there are secure things to switch to. That's literally the primary reason why the SHA-3 contest happened -- SHA-2 was strong, but it was the only fairly standard strong hash, and NIST wanted an alternative if it was broken.

Improve this answer
$\endgroup$

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.