Benchmarking

Recommendation

If you’re on a server with a modern CPU, grab libaegis, and use its aegis256x4. It’s 5x faster than any other encryption, and being authenticated encryption, means one doesn’t need to compute an additional data checksum. Even if the use case doesn’t require authenticated encryption, it’s 4x faster than OpenSSL’s AES-CTR, so one can use the detached function variants to just discard the authentication tag.

If you’d prefer to rely on a more reputable library, libsodium includes an equivalent AEGIS(x1) implementation, which runs at half the speed of AEGISx4, but still twice as fast as OpenSSL’s AES-GCM.

Benchmark

Looking at two unauthenticated encryption modes: CTR and XTS. Due to being unauthenticaed, they’ll require a checksum over the plaintext to detect bitrot corruption, which is XXHash’s XXH3. This defines two pseudo-modes, CTRXXH and XTSXXH, which calculate a checksum before encryption and validate it after decryption as part of the benchmark.

Looking at two authenticated encryption modes: GCM and OCB, and an authenticated encryption algorithm, AEGIS. Authenticated encryption validates the decrypted output as untampered along with decryption, so it doubles as a data checksum.

We’ll be comparing these across the various popular encryption libraries, taking whichever ones each library supports:

transactionalblog/encryption-at-rest

Comparing five methods of encryption:

Setup

CPU supported intrinsics Kernel system configuration

Results

Analysis

The overwhelmingly poor results of WolfSSL is due to AES-NI support not being enabled. The CMake configuration for WolfSSL does not allow enabling the {uri-wolfssl-cmake-aesni}[intel intrinsics], nor does it permit enabling {uri-wolfssl-cmake-xts}[AES-XTS].

Botan’s API forces the use of its own Botan::secure_vector<> type for input. The idea behind this is that the destructor will overwrite the contents, ensuring that data won’t be leaked. Botan also only supports in-place encryption. The combination of these means that two extra memcpy()s are required to copy data into and out of the temporarily allocated secure_vector<>. The performance is also likely slightly more unstable as it’s the only library which also forces performing memory allocations on the critical encryption/decryption path (for both the cipher context, and for the secure_vector<> storage space).

Crypto++ is another very C+\+-ified API, but done in a way that doesn’t require memcpy. It still does require memory allocations on the critical encryption/decryption path though.

LibTomCrypt was a significant disappointment. All results had to be discarded. CTR, GCM, and OCB modes report running faster than memcpy, thus implying they returned early but didn’t signal an error. XTS crashes when cleaning internal state. Even linking to the library with vcpkg was more of a hassle than all other libraries. I’ve double checked my usage against LibTomCrypt’s tests and with GPT, and both seem to confirm the code seems correct. Some of the APIs are terrifying: you’re allowed to specify the number of rounds for AES-CTR (and only AES-CTR?). Even if the library worked in the benchmark, I double it would show stellar performance, as the encryption modes are layered onto the encryption cipher independently, rather than fused together as the more optimized libraries do.