AES speed compared to permuted LCG

What is the speed of AES and how to estimate it well? Here:

https://security.stackexchange.com/questions/92074/aes-algorithm-encryption-time

they wrote it could be 700 MB/s. But here:

https://www.cse.wustl.edu/~jain/cse567-06/ftp/encryption_perf/index.html

Abdel-Karima Al Tamima estimated it is about 50 MB/s. Why are there such differences? Is it because of some kind of hardware acceleration? I'm trying to compare it to PCG generators:

https://www.pcg-random.org/paper.html

Just to compare what is faster in generating pseudorandom numbers (I know that PCG is not cryptographically secure and it is not a cipher). For example 128-bit PCG XSL RR RR can proceed about 65 GB/s (it was probably implemented in numpy of Python). Is it comparable to 50 MB/s or 700 MB/s?

• Are we using a CPU with AES instructions or not? – Eugene Styer Apr 26 at 2:32
• Where did you get the "65 GB/s" number from? Assuming 4 GHz frequency, that is over 16 bytes per cycle (while it's impossible for the generator to return more than 8 per call). It's also far above the maximum DDR4 bandwidth. Also, numpy and python will be very slow for running the generator sequentially (and running multiple generators in parallel or operating on an array of generator states isn't a fair comparison). – the default. Apr 26 at 4:17
• That estimation of 50 MB/s was performed on a "P-II 266 MHz and P-4 2.4 GHz". Uh. My lowly laptop manages 180 MB/s on a single core, which I think is worryingly low for AES-NI instructions. – Maarten Bodewes Apr 26 at 9:47
• What CPU are you interested in for performance numbers / for the comparison? Both, AES and PCG performance will vary / compare wildly differently depending on the answer. Also related on Matter Modelling. – SEJPM Apr 26 at 10:09
• @EugeneStyer I think to compare it well we should not, because PCG also pcg also doesn't use any supporting instructions. – Tom Apr 26 at 15:13

AES is generally very fast when implemented in hardware. On my laptop, a Core i7 8665U, AES-128 operates at 6758 MB/s. It is slower when implemented in software, and it is much slower when implemented in software in a constant-time implementation. A naive software implementation that is not constant time runs as 367 MB/s on my system.

You mentioned that you're looking for smartphone processors. Some of the newer processors will have AES acceleration available, but not all will. If you're looking for an algorithm that will perform well on almost all systems, be constant time, and cryptographically secure, I'd recommend ChaCha20, or, if you really need screaming performance, ChaCha12. ChaCha20 on my system runs at 3513 MB/s and will clearly outperform AES where hardware acceleration is not present. ChaCha12 performs almost as well as or better than many non-cryptographic PRNGs. It would be my choice for a PRNG, whether cryptographic or non-cryptographic, because it is fast, secure, and has no weak seeds (unlike many non-cryptographic PRNGs). It is also the default PRNG for the Rust rand family of crates, and ChaCha20 is used in the Linux kernel to generate random numbers.

Note that any performance comparison of PRNGs also has to consider not just generating the values but getting them into a place where they can be used. For example, AES-NI instructions would probably perform even better than I listed above if you only encrypt the same data in place using vector registers. However, the performance drops off when you must load and store data to and from memory because that is more expensive. I suspect the PCG paper does not take that into account in a practical way.

Of course, performance measurements on my system are not reflective of other systems and if you need to know how things work on a particular system, you should benchmark it yourself. You may also want to look at SUPERCOP, which benchmarks many cryptographic primitives on various types of hardware to answer your questions. It's likely that you'll find hardware that is comparable to modern and older processors, including a variety of ARM and ARM64 hardware.

A final note about performance: you don't always need to use the fastest algorithm for a job. It is likely that in most applications, the generation of random numbers is not the bottleneck, and the benefits of using an algorithm like ChaCha (such as its lack of weak states and better quality) may outweigh the fact that it is slightly slower. Your benchmarking would need to focus on identifying places that are a bottleneck, and improving those whenever possible.

• My second requirement is low memory usage. That's why I was skeptical about AES. I think Chacha20 still needs more space than 128-bit PCG XSL RR RR. I don't know, I'm not an programmer or a cryptographer, but from what I've read I assume that AES and Chacha20 need more RAM. So if PCG is much faster - I prefer PCG. And one more thing - it has to be invertible. – Tom Apr 28 at 5:37
• ChaCha uses 128 bytes of RAM, plus 16 bytes of constants. It should be suitable for all but the tiniest embedded devices. AES in hardware requires nothing and AES in software requires significant tables of constants. It isn't clear to me what you mean by invertible. ChaCha can be random-access so you can generate values anywhere in the stream, but knowing the output you cannot derive the input, since that would be insecure and not suitable for a CSPRNG. – bk2204 Apr 28 at 22:32
• Ok. So in case of RAM it is quite clear to me, but PCG still needs less of RAM. And when it comes to speed, here: opendatascience.com/…, they estimate 64-bit PCG needs 1,27 cycles per byte (it could be similar with 128-bit PCG). And Salsa20 offers 4-14 cycles per byte, probably a bit less on modern devices. And AES wihtout hardware acceleration is for sure slower. – Tom Apr 28 at 23:03
• If what you want to use is PCG, then use it. However, it provides lower quality numbers: PCG is predictable given 512 bytes of output, and AES and ChaCha are not. Maybe that's okay for your use case if your use case isn't cryptographic, but only you can decide that. – bk2204 Apr 29 at 1:17