10
$\begingroup$

I am using the AES cipher for my OTT platform. Almost all Chip vendors (ARM, Intel, etc) have built-in AES for faster and secure processing.

  • Now, how feasible it is to move from AES to ChaCha20? What are the pros and cons of this?
  • Will ChaCha20 be faster than in-built hardware support for AES?
  • Can ChaCha20 provide better security over AES over the years?
  • Do we have any comparison document where it shows performance(cipher speed) over various resolutions starting from 576i to 4K over various bitrate from 2 Mbps to 20 Mbps?
Improve this question
$\endgroup$

2 Answers 2

Reset to default
9
$\begingroup$

Now, how feasible it is to move from AES to ChaCha20? What are pros and cons of this?

This entirely depends on the platform and implementation. There's no way we can answer this definitively. However it's usually not particularly difficult to change one cipher to another.

Will ChaCha20 be faster than in-built hardware support for AES?

Software ChaCha20 will be slower than hardware AES, but not by much. It will however be much faster than software AES, which is why many people use it. It's also easier to write a timing attack-free implementation in software (hardware AES is resistant to timing attacks, but pure software implementations of AES that are resistant are often much slower).

Can ChaCha20 provide better security over AES over the years?

No way to know. They're both very secure and show no signs of meaningfully weakening.

Do we have any comparison document where it shows performance(cipher speed) over various resolution starting from 576i to 4K over various bitrate from 2mbps to 20 mbps?

A cipher doesn't care about resolution, just data. Any data-based comparison would require knowing exactly what hardware you use and what software you run on it. Let's assume ChaCha20-Poly1305 vs AES-GCM. The answer is simply that the former is faster in a software-only implementation, but AES comes out ahead if the device has anything like AES-NI (even more so if it can also accelerate GCM with something like PCLMULQDQ). But you're probably looking in the wrong place for an optimization. You won't gain much speedup by switching ciphers. Consider changing codecs.

Related: What's the appeal of using ChaCha20 instead of AES?

Improve this answer
$\endgroup$
7
  • $\begingroup$ "Software ChaCha20 will be slower than hardware AES, but not by much" Do you have any test data to back that up? I've seen a claim that ChaCha20 is about three times faster than AES on some devices. If it's only three times faster then hw AES could be many times faster than ChaCha20 in some situations. $\endgroup$
    – Swashbuckler
    Commented Mar 7, 2021 at 15:29
  • $\begingroup$ @Swashbuckler It can be three times faster on devices that don't have hardware-accelerated AES instructions. If you have the cipher in hardware, then it's exceptionally fast. See security.googleblog.com/2014/04/… for some performance evaluations. $\endgroup$
    – forest
    Commented Mar 7, 2021 at 23:00
  • $\begingroup$ @forest as you can see from my table, that is worse on OpenSSL due to secure implementations. It is 28 times slower. $\endgroup$
    – kelalaka
    Commented Mar 8, 2021 at 8:00
  • $\begingroup$ @Swashbuckler ECRYPT has some benchmarks for implementations of both AES and Chacha; see here bench.cr.yp.to/results-stream.html. It indeed shows that Chacha20 is barely slower than AES128-NI when AVX512 are available, and around twice slower when only AVX2 are available (and less than twice slower than AES256-NI). $\endgroup$
    – Dada
    Commented Mar 8, 2021 at 9:24
  • 1
    $\begingroup$ @Ruggero I'm skeptical that such power analysis attacks would work against a modern x86 processor for an ARX scheme, but I'm not an expert in that. I was thinking about power analysis attacks against the x86 cache as far as AES is concerned, which is relatively easy to pull off. I've edited my answer again to specify only timing attacks. $\endgroup$
    – forest
    Commented May 22, 2023 at 9:26
6
$\begingroup$

Will ChaCha20 be faster than in-built hardware support for AES?

Do we have any comparison document where it shows performance(cipher speed) over various resolutions starting from 576i to 4K over various bitrate from 2 Mbps to 20 Mbps?

OpenSSL has a speed command. If you consider that it is regularly patched against the founded insecurities, it is always a good base to compare ciphers.

The below is the performance comparison of the AES-256-GCM, AES(NI)-256-GCM, ChaCha20-Poly1305 (OpenSSL always use ChaCha with 256-bit key) on my Intel I7- 7. gen

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
chacha20 367799.29k 702973.21k 1416296.19k 2988179.46k 3125635.75k 3059062.10k
aes-256-ctr 185286.74k 188173.99k 210752.17k 211406.17k 202839.38k 206531.24k
aes-256-ctr(NI) 504215.69k 1744835.29k 2940341.50k 3477252.44k 3773789.53k 3864182.78k
chacha20-poly1305 259679.98k 511848.38k 1004036.78k 1912721.38k 2046227.80k 1997160.45k
aes-256-gcm 101014.33k 124328.36k 129647.19k 134264.83k 133802.67k 134146.73k
aes-256-gcm (NI) 410064.16k 1119080.51k 2036770.90k 2994741.59k 3582448.98k 3772132.01k

Run commands

$openssl speed -evp chacha20
$OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-256-ctr
$openssl speed -evp aes-256-ctr
$openssl speed -evp chacha20-poly1305
$OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-256-gcm
$openssl speed -evp aes-256-gc

Can ChaCha20 provide better security over AES over the years?

That depends on the key sizes. OpenSSL always uses ChaCha20 with 256-bit key sizes when compared to AES-256 we don't expect any problem on both ciphers even the quantum computers are built.

128-bit key size is problematic in two ways; multi-target attack and quantum attacks. That is why we prefer 256-bit key sizes. That mitigates all.

Also see, below;

Now, how feasible it is to move from AES to ChaCha20? What are the pros and cons of this?

Mode of Operation

We don't use AES as it is since it is primitive, however, ChaCha20 is designed in CTR mode. We need a mode of operation for AES, too. The most common ones AES-GCM and ChaCha20-Poly1305.

Poly1305 uses $\mathbb Z/(2^{130} - 5)\mathbb Z$ and is easy to implement in software without timing side channels.

GCM uses GHASH and that uses arithmetic in the binary field $\operatorname{GF}(2^{128})$. It has hardware support, if you don't use hardware, it will be slow in software without timing side channels.

There are technical differences, too.

PRF vs PRP

  • AES is a pseudorandom permutation (PRP) family of 128-bit blocks.
  • ChaCha is a pseudorandom function (PRF) family from 256-bit inputs to 512-bit outputs.

In most of the protocols, due to the AES is PRP, it is unsafe to encrypt more than $2^{64}$ blocks, however, ChaCha20 has no practical limit on this.

We can say ChaCha20 is better for the CTR mode than AES. Note that ChaCha20 is using the CTR mode by design.

Key schedule

AES key schedule has a cost to generate the subkeys while in ChaCha20 it has no cost. So if your protocol requires lots of new keys, ChaCha20 is better than AES.

Nonce

There is a variant of ChaCha20 that is XChaCha20 that uses 192-bit nonces. This is better than AES-GCM on generating random nonces. The $(key,IV)$ pair reuse problem is almost impractical on randomly generated nonces on XChaCha20, however, on should stop way earlier than $2^{48}$ random nonces on AES-GCM due to the birthday bound. If you stick to ChaCha20 then it has 128-bit nonces, too, the same problem.

One can use nonce-misresistant AES-GCM-SIV to eliminate the nonce reuse problem. This brings additional performance cost, though.

Side-channel

Since ChaCha20 uses ARX design that helps easy to implement against timing side-channel attacks. As one can see from the above table, the secure software implementation of AES is terribly slow. ChaCha20 is around %20 slower compared to AES-NI-256.

Number of round

AES-256 has 14 rounds and ChaCha20 has 20. The attack on the reduced rounds that is cheaper than brute-force seems around 7 for both ciphers. This means that ChaCha20 has a better security margin than AES.

In short, go for XChaCha20-Poly1305 where available. AES-GCM has many pitfalls.

Improve this answer
$\endgroup$
10
  • 1
    $\begingroup$ I don't think ChaCha is considered to be running "CTR mode". It's very similar in that you feed a counter, but CTR uses a block cipher and you add nonce + counter and encrypt with key, whereas ChaCha uses nonce + counter + key and runs through a public permutation. $\endgroup$
    – forest
    Commented Mar 7, 2021 at 23:10
  • $\begingroup$ @forest Each stream block is determined by its position, the nonce, the key, and the previous blocks of plaintext—equivalently, the previous blocks of ciphertext. Salsa20 follows this model, as does any block cipher in counter mode, from salsa20 paper. Also, Diffie-Hellman:Privacy and Authentication: An Introduction to Cryptography describes CTR first for PRF later PRP and mentions a possible problem the later called the PRF-PRP switching lemma. $\endgroup$
    – kelalaka
    Commented Mar 7, 2021 at 23:24
  • $\begingroup$ Ah interesting. I think someone corrected me on this before but I just forgot. Also, 128-bit key size is problematic in two ways; multi-target attack – This is why if you have to use 128-bit keys, use a random non-zero nonce! That mitigates it just as well as using 256-bit keys. $\endgroup$
    – forest
    Commented Mar 8, 2021 at 1:21
  • $\begingroup$ forgot to mention, that we uses AES-256 in CTR mode. $\endgroup$
    – SSA
    Commented Mar 8, 2021 at 4:30
  • $\begingroup$ @SSA AES-GCM already uses CTR mode for encryption. Most arguments still apply there and you should still use them in authenticated modes like AES-GCM and ChaCha20-Poly1305. $\endgroup$
    – kelalaka
    Commented Mar 8, 2021 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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