# How much is slower GCM AES-128 than one of the stream chipher eSTREAM?

Evaluate the speed of the algorithm GCM AES-128 and compare it whith speed of one of the stream chipher in eSTREAM. Can someone give such an assessment?

-
1) That's an apples to oranges comparison. eSTREAM is about unauthenticated stream ciphers, you need to compare with AES-CTR. 2) Which CPU? With AES-NI it's really fast, faster than eSTREAM ciphers. On other CPUs it can it might be 5x slower,... 3) with or without side-channel protection? Implementations of GHASH on CPUs without specialized instructions uses large lookup tables, leading to low key agility and potential cache timing attacks. –  CodesInChaos Oct 12 '13 at 20:42
compare AES-CTR and eSTREAM generalized analysis regardless of platform or processor –  NiceTheo Oct 12 '13 at 20:48
The first place to go for performance checks is eBACS. Unfortunately it has its flaws. In particular I suspect that its AES implementations are far from optimal on some platforms. –  CodesInChaos Oct 12 '13 at 20:51
@NiceTheo There is an AES-CTR implementation in eBACS, see aes128estream and aes256estream. –  orlp Oct 12 '13 at 21:37
You really cannot make a comparison which does not depend on the actual hardware. AES-128 + GCM will totally rule on modern x86 which has dedicated opcodes just for that task; on a small ARM or Mips with small L1 cache, GCM will be substantially slower than, say, Sosemanuk (or even Sosemanuk+HMAC/SHA-1, since GCM includes a MAC). –  Thomas Pornin Oct 13 '13 at 14:38

eBACS, as given by CodesInChaos, is a great resource, and it provides much more data than I could hope to give in this answer. However, the page is not explicit about whether or not AES-NI was used — looking at the results, it doesn't seem so.

For an extremely shallow analysis, but allowing us to know for-sure about hardware acceleration, we can use the command-line tool gnutls-cli, which uses GnuTLS to benchmark some ciphers. Some sample output:

[reid@reid-pc] ~ % gnutls-cli --benchmark-ciphers
SALSA20-256-SHA1 0.30 GB/sec
AES-128-CBC-SHA1 0.33 GB/sec
AES-128-CBC-SHA256 0.21 GB/sec
AES-128-GCM 1.34 GB/sec
SHA1 0.56 GB/sec
SHA256 0.29 GB/sec
SHA512 0.44 GB/sec
3DES-CBC 26.96 MB/sec
AES-128-CBC 0.75 GB/sec
ARCFOUR-128 0.51 GB/sec
SALSA20-256 0.64 GB/sec


So, on my system (which has an Intel i5 Ivy Bridge and thus the AES-NI instruction set), AES-GCM processes data at about 1.34 GB/sec while Salsa20-256 with HMAC-SHA1 only manages 0.30 GB/sec.

However, it's thanks to the aforementioned AES-NI instruction set that AES-GCM fares so well. gnutls-cli has another argument to turn off hardware acceleration:

[reid@reid-pc] ~ % gnutls-cli --benchmark-soft-ciphers
SALSA20-256-SHA1 0.30 GB/sec
AES-128-CBC-SHA1 175.29 MB/sec
AES-128-CBC-SHA256 136.43 MB/sec
AES-128-GCM 169.09 MB/sec
SHA1 0.57 GB/sec
SHA256 0.29 GB/sec
SHA512 0.44 GB/sec
3DES-CBC 26.97 MB/sec
AES-128-CBC 0.25 GB/sec
ARCFOUR-128 0.51 GB/sec
SALSA20-256 0.64 GB/sec


Note here that Salsa20-256 with HMAC-SHA1 outperforms AES-GCM. So, if your requirements allow you to use the AES-NI instruction set (e.g. the near-latest Intel chips), then AES-GCM is definitely the way to go. On the other hand, if your specs are more modest, you may want Salsa20-256 with HMAC-SHA1.

Another benchmarking tool is openssl speed, but it doesn't support Salsa20. Running a benchmark on AES-GCM with openssl speed -evp aes-128-gcm, I get about 1.33 GB/sec, similar to GnuTLS.

-
One may add that in order to encrypt 300 MB/s worth of data, you must have 300 megabytes worth of data to encrypt every second. Gigabit ethernet will saturate much before that (around 110 MB/s if you are lucky). That's the limit of microbenchmarks: they don't necessarily tell you much about performance of a complete system in a practical situation. –  Thomas Pornin Oct 13 '13 at 14:35
eBACS clearly uses AES-NI on some CPUs for aes128ctr but apparently it does not for aes128estream. On CPUs with AES-NI, it seems to run AES-128 at 1.3 cycles-per-byte, but without it costs over 10 cpb. –  CodesInChaos Oct 21 '13 at 14:41