Previously, and earlier, we looked at modernizing the TLS configuration of OpenVPN. However, TLS is not the only cryptography used by OpenVPN. There’s also the data channel. This post will look into using another data channel encryption algorithm to see whether it can be beneficial for OpenVPN performance and under what circumstances.
There are a number of options when choosing a cipher for the data channel. The most obvious one, and until very recently, the best available in OpenVPN is AES-GCM. This algorithm has been used from the start by eduVPN.
Recently OpenVPN 2.5 was released which supports a modern cipher that can be used for data channel encryption: ChaCha20-Poly1305 as described in RFC 7539.
Most common CPUs have instructions to speed up AES-GCM and implement AES-GCM in constant time, reducing the likelihood of a successful side channel attacks against the cipher. However, not all hardware has it, for example the Raspberry Pi (still) does not have it. We’ll analyze the difference in performance of these ciphers both on devices with AES-GCM hardware support and without.
There may also be other reasons not to use AES, irrespective of hardware acceleration. And of course, one has to trust the CPU to properly implement AES-GCM and adequately prevent side channel attacks. Trusting your CPU is not a given, as was demonstrated over the last years. Not all CPUs are entirely flawless, it turned out, starting with the Meltdown “revelations”. It may be wise not to trust your hardware to prevent side channel attacks and instead opt for an algorithm that is side channel attack resistant by design, i.e. ChaCha20-Poly1305.
We’ll do some rudimentary performance analysis of the algorithms using the OpenSSL command line tool:
for ALG in aes-256-gcm chacha20-poly1305; do
openssl speed \
-evp ${ALG} \
-bytes 1500 \
2> /dev/null | grep "^${ALG}"
done
This should give us a rough indication what the difference in algorithms will do to the performance of OpenVPN. If you want to replicate this on your own hardware, you need a relatively recent version of OpenSSL, as old(er) versions do not have the -bytes option, and even older version do not even have ChaCha20-Poly1305 support…
Comparison
We’ll be using an older Lenovo X230 (2012), a Raspberry Pi 3B+, a Raspberry Pi 4 and a ROCKPro64.
Let’s see how the different platforms compare against each other. We used Fedora 33 (x86_64, aarch64), Raspbian (armv7) and Debian 11 (aarch64).
| Device | Algorithm | Speed (kB/s) | Speed (%) |
|---|---|---|---|
| Lenovo | aes-256-gcm |
979,299 | 100 |
chacha20-poly1305 |
701,373 | 71 | |
| Raspberry Pi 3B+ (Fedora) | aes-256-gcm |
25,586 | 100 |
chacha20-poly1305 |
159,755 | 624 | |
| Raspberry Pi 3B+ (Raspbian) | aes-256-gcm |
39,121 | 100 |
chacha20-poly1305 |
172,564 | 441 | |
| Raspberry Pi 4B (Fedora) | aes-256-gcm |
24,001 | 100 |
chacha20-poly1305 |
225,715 | 940 | |
| Raspberry Pi 4B (Raspbian) | aes-256-gcm |
53,353 | 100 |
chacha20-poly1305 |
215,974 | 404 | |
| ROCKPro64 (Debian 11) | aes-256-gcm |
834,172 | 100 |
chacha20-poly1305 |
271,512 | 32 |
On x86_64 the result is quite clear: you can expect more performance from AES-GCM than ChaCha20-Poly1305 when accelerated AES is available. On the Raspberry Pi it is quite different. ChaCha20-Poly1305 is much faster. Furthermore it is interesting to see the difference between Fedora and Raspbian. Either Raspbian knows some tricks to make AES-GCM faster which were not upstreamed, or the difference can be explained by Raspbian being 32 bit, and Fedora being 64 bit. We did not investigate further. The ROCKPro64 clearly is a lot faster with AES as it has the ARMv8 Cryptography Extensions.
Conclusion
In order to get the best performance in all cases, it may make sense to allow the client (or server?) to pick the algorithm to use. For example on slower devices, mostly (older) mobile devices may be much better off with ChaCha20-Poly1305 than AES-256-GCM and thus be faster and save battery. An exercise for the reader might be to run the OpenSSL performance tests on their mobile devices 🙂
Special thanks to Jan Just Keijser for help with interpreting the OpenSSL speed results and his work on OpenVPN performance testing.
Add Comment