wjd.nu

2020-05-13 - encryption decryption speed / gnupg / openssl

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):

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

collect-enc-dec-samples.sh - Run tests N times
samples.log.bz2 - Raw results
aggregate-enc-dec-samples.sh - Drop outliers and produce average CSV
results.csv - Aggregated results
results.ods - Results in a spreadsheet

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
;Encryption;;;;Decryption;;;;
;user (ms);sys (ms);total (ms);mem (10K);user (ms);sys (ms);total (ms);mem (10K);
g1.4;7645;354;7999;354;15738;322;16060;359;
g2.2;2863;340;3203;507;6212;340;6552;515;
g2.3;2752;281;3033;527;4494;318;4812;536;
n2.3;4508;281;4789;525;7547;318;7865;537;
ossl;1754;339;2093;506;421;391;812;506;
osno;3564;344;3908;504;2765;396;3161;507;
cust;3338;421;3759;2458;3565;435;4000;2461;

2020-05-01 - encryption / vocabulary / long term storage

While investigating the most appropriate encryption cipher and format, I realised I didn't have enough vocabulary on the subject. This post aims to close that knowledge gap somewhat.

I'm looking at symmetric ciphers here, as they are used when storing lots of data. (In fact, when encrypting larger amounts of data, public/private key encryption (an asymmetric cipher) is only used to encrypt a separate key for the symmetric cipher, which is then used for bulk of the data.)

Initially, our objective was to find a suitable encryption file standard that satisfies the following properties:

For symmetric file encryption, we'll need the following ingredients:

With all of those ingredients on the table, a sample encryption pass with GnuPG might look like this:

$ time gpg --batch \
    --symmetric --passphrase-file ./password.txt \
    --s2k-mode 3 --s2k-digest-algo SHA512 \
    --cipher-algo AES256 \
    --output ./encrypted.gpg \
    ./original.txt

real  0m10.923s
user  0m10.743s
sys   0m0.180s

Pretty slow. Let's disable (the default ZLIB) compression:

$ time gpg --batch \
    --symmetric --passphrase-file ./password.txt \
    --s2k-mode 3 --s2k-digest-algo SHA512 \
    --compress-algo none \
    --cipher-algo AES256 \
    --output ./encrypted-no-compression.gpg \
    ./original.txt

real  0m3.725s
user  0m3.136s
sys   0m0.588s

Much better, but now our sample file is larger. Let's add very lightweight qlzip1 (qpress) in the mix. (See QuickLZ and qpress-deb.)

$ time gpg --batch \
    --symmetric --passphrase-file ./password.txt \
    --s2k-mode 3 --s2k-digest-algo SHA512 \
    --compress-algo none \
    --cipher-algo AES256 \
    --output ./encrypted.qz1.gpg \
    <(qlzip1 < ./original.txt)

real  0m1.402s
user  0m1.486s
sys   0m0.203s

Now we're getting somewhere. Aside from the highly compressible (json) original.txt, we've produced the following files in the mean time:

$ du -sh original.txt encrypted*
   959M original.txt
    90M encrypted.gpg
   959M encrypted-no-compression.gpg
    86M encrypted.qz1.gpg

Checking the key derivation s2k-count and s2k-digest-algo, to get a feeling for the key derivation speed:

$ for c in 65011712 8388608 65536; do
    for a in SHA1 SHA256 SHA512; do
      rm -f ./encrypted-1-one-byte.qz1.gpg
      out=$(a=$a c=$c bash -c '\
        time gpg --batch \
          --symmetric --passphrase-file ./password.txt \
          --s2k-mode 3 --s2k-digest-algo $a --s2k-count $c \
          --compress-algo none \
          --cipher-algo AES256 \
          --output ./encrypted-1-one-byte.qz1.gpg \
          <(qlzip1 < ./1-byte-file.txt)' \
        2>&1)
      printf 't %s count %8d algo %6s\n' \
        $(echo $out | awk '{print $2}') $c $a
    done
  done
t 0m0.490s count 65011712 algo   SHA1
t 0m0.373s count 65011712 algo SHA256
t 0m0.275s count 65011712 algo SHA512
t 0m0.068s count  8388608 algo   SHA1
t 0m0.052s count  8388608 algo SHA256
t 0m0.039s count  8388608 algo SHA512
t 0m0.003s count    65536 algo   SHA1
t 0m0.004s count    65536 algo SHA256
t 0m0.005s count    65536 algo SHA512

So, as promised, taking a longer hash results in fewer S2K iterations: the 2 x SHA-512 hash equivalents of 250.000, 32.000 and 250 rounds, respectively. Notice how the elapsed time quickly drops from half a second to milliseconds.

This is where strong (high entropy) passwords come into play. If the password is as random as the derived key would be we don't need to do any sizable derivation pass. That is, unless we want to slow people (both legitimate users and attackers) down on purpose. (If someone is trying to crack our file, they might as well skip the derivation step and guess the key instead. Only if they also want our (master) password, should they do the derivation. Rotating the password every so often mitigates this.)

Okay. So what about OpenSSL? How does OpenSSL enc compare?

$ time gpg --batch \
    --symmetric --passphrase-file ./password.txt \
    --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 65536 \
    --compress-algo none \
    --cipher-algo AES256 \
    --output encrypted.qz1.gpg <(qlzip1 < ./original.txt)

real  0m1.097s
user  0m1.186s
sys   0m0.171s

$ time openssl enc -e -pass file:./password.txt \
    -pbkdf2 -md sha512 -iter 250 -salt \
    -aes-256-cbc \
    -out encrypted.qz1.ossl-pbkdf2-250-sha512-aes256cbc \
    -in <(qlzip1 < original.txt)

real  0m1.072s
user  0m1.047s
sys   0m0.197s

Pretty comparable! But, note how we have to store ossl-pbkdf2-250-sha512-aes256cbc somewhere, because only the key derivation salt is stored in the clear.

And, the OpenSSL version does not even include error detection!

So, we've looked at GnuPG and OpenSSL. What about zip? 7zip? Any others?

Both zip and 7-zip don't only do compression and encryption, they also do file archiving. Archiving is not something we're looking for here. Nor is their compression. Even if we made sure that the contents were encrypted when decrypting (needed for integrity purposes), we'd still be using the wrong tool for the job. Did I mention that streaming (on-the-fly) encryption/decryption is a pre? Which they can't do. Being able to chain tools together keeps memory low and usability high.

What about something homegrown?

Well yes, for the full comparison experience, I happen to have a private customer-built custom encryption tool — with a custom file format — laying around: let's call it customcrypt.py. It uses PBKDF2HMAC(algorithm=SHA512, iterations=250) for key derivation, and HMAC(derived_key2, algorithm=SHA256) for Encrypt-then-MAC verification and a ChaCha20 stream cipher (hence no block mode required).

$ time python3 customcrypt.py \
    -e <(qlzip1 < original.txt) \
    encrypted.qz1.custom

real  0m1.212s
user  0m1.321s
sys   0m0.180s

Not too shabby either. (Although I question the usefulness of deriving an integrity key from the same password.) The drawback of this particular file format is that it hardcodes some parameters, i.e.: it's not self-documenting. (A problem we can fix.) But also, in 10 years, this script may get lost or have broken dependencies. (A problem that's harder to fix.)

For the tests above, GnuPG 2.2.4 (on Ubuntu/Bionic) was used. Algorithm availability on the CLI:

$ gpg --version
gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
...
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

For OpenSSL the version was 1.1.1 (also Ubuntu). Algorithms can be found thusly:

$ openssl help
...
Message Digest commands (see the `dgst' command for more details)
blake2b512        blake2s256        gost              md4
md5               rmd160            sha1              sha224
... (elided a few) ...
Cipher commands (see the `enc' command for more details)
aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb
aes-256-cbc       aes-256-ecb       aria-128-cbc      aria-128-cfb
... (elided a few) ...

Next time, we'll look at symmetric cipher speed, which is the last factor in the mix. Then we can make a final verdict.