6
$\begingroup$

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?

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ 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. $\endgroup$
    – CodesInChaos
    Commented Oct 12, 2013 at 20:42
  • $\begingroup$ compare AES-CTR and eSTREAM generalized analysis regardless of platform or processor $\endgroup$
    – NiceTheo
    Commented Oct 12, 2013 at 20:48
  • 2
    $\begingroup$ 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. $\endgroup$
    – CodesInChaos
    Commented Oct 12, 2013 at 20:51
  • 1
    $\begingroup$ @NiceTheo There is an AES-CTR implementation in eBACS, see aes128estream and aes256estream. $\endgroup$
    – orlp
    Commented Oct 12, 2013 at 21:37
  • 3
    $\begingroup$ 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). $\endgroup$
    – Thomas Pornin
    Commented Oct 13, 2013 at 14:38

1 Answer 1

Reset to default
11
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • 6
    $\begingroup$ 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. $\endgroup$
    – Thomas Pornin
    Commented Oct 13, 2013 at 14:35
  • 1
    $\begingroup$ 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. $\endgroup$
    – CodesInChaos
    Commented Oct 21, 2013 at 14:41

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.