Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
up vote 8 down vote accepted

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
Checking ciphers, payload size: 16384
     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
Checking ciphers, payload size: 16384
     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.

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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