encryption decryption speed / gnupg / openssl

encryption decryption speed / gnupg / openssl

  • Written by
    Walter Doekes
  • Published on

We were looking at encryption ingredients the other day. Because, if we want to compare encryption methods, we shouldn’t compare apples and oranges. With that newfound knowledge, we can run a few speed tests.

The aggregated data (raw data sources can be found below):

user (ms)sys (ms)total (ms)mem (10K) user (ms)sys (ms)total (ms)mem (10K)
gpg 1.4 76453547999354 1573832216060359
gpg 2.2 28633403203507 62123406552515
gpg 2.3* 27522813033527 44943184812536
gpg 2.3* nohw 45082814789 52575473187865537
openssl 17543392093 506421391812506
openssl nohw 35643443908504 27653963161507
customcrypt 333842137592458 356543540002461

AES-256 encryption/decryption speedgraph

First a few notes about the graph:

  • Lower is better: both for time and memory usage. It’s sorted by decryption speed.
  • Compression is off, key derivation is minimal: most time will be spent in the symmetric cipher.
  • The nohw variants of GnuPG and OpenSSL run with Intel AES-NI disabled: no hardware acceleration.
  • Total time is simply user time + system time as there was no parallelism. System time deviates only a little between the methods.
  • The memory bar shows the max. resident set size (in 10KB units).

We can make the following observations from the above graph:

  • OpenSSL is fastest. It’s also the dumbest, without any integrity checks. But even without AES-NI, it outperforms GnuPG decryption.
  • While you expect little or no difference, OpenSSL decrypts faster than it encrypts, and the inverse is true for GnuPG: for stable versions even by factor of two!
  • AES-NI hardware acceleration matters. But so does application performance.
  • GnuPG has been improving its performance, but they’re not there yet.

Conclusion time!

We were looking for the right tool for long term storage of data and a couple of options were reviewed. GnuPG AES-256 decryption time is 6 times as slow as OpenSSL. However, it still wins by usability and compatibility.

I know, that conclusion is not what the graph is telling us. But decryption speed is not everything. (In fact, most of our long term data will probably never be decrypted at all.) And I’m also confident that future versions of GnuPG will close the gap some more.

No hardware acceleration (nohw): no aes-ni CPU support

To disable CPU AES support in the results marked with nohw, two methods were employed. For OpenSSL AES-NI can be can be disabled using: OPENSSL_ia32cap="~0x200000200000000". For libgcrypt — used by GnuPG — a tiny library preloader was used:

/* gcc gcrypt-no-aesni.c -fPIC -shared -Wl,-init,init -lgcrypt \
     -o gcrypt-no-aesni.so  # LD_PRELOAD to disable 'aes-ni' for GnuPG */
#include <gcrypt.h>
void init() { gcry_control(GCRYCTL_DISABLE_HWF, "intel-aesni", NULL); }

Versions used

  • gpg 1.4.22 (Ubuntu/Bionic, 1.4.22-3ubuntu2)
  • gpg 2.2.4 (Ubuntu/Bionic, 2.2.4-1ubuntu1.2)
  • gpg 2.3.0-beta516 (gnupg-2.3-base-257-g643ec7c64 patched to make it build on Bionic.
  • libgrypt 1.8.1 (Ubuntu/Bionic, 1.8.1-4ubuntu1.2)
  • openssl/libssl 1.1 (Ubuntu/Bionic, 1.1.1-1ubuntu2.1~18.04.5)
  • A custom python3 script which uses ChaCha20 instead of AES-256-CBC. It’s included because it was also in my previous post.

Detailed graph sources


The data was gathered by setting ITERATIONS to 120 and running all methods sequentially. Then the 5% fastest and slowest results were dropped.

$ ./collect-enc-dec-samples.sh >samples.log

$ ./aggregate-enc-dec-samples.sh samples.log >results.csv
(taking average 7..114 results from 'samples.log')

$ cat results.csv
;user (ms);sys (ms);total (ms);mem (10K);user (ms);sys (ms);total (ms);mem (10K);

Back to overview Newer post: more or less useless tips and tricks 3 Older post: encryption / vocabulary / long term storage