To make it simple for you to reproduce the results we’re about to show, we will again use the OpenSSL Docker image. It goes without saying that if you want to obtain performance results for a specific system, for example, a specific instruction set architecture, you should run the following commands on the native installation.

To benchmark the performance of cryptographic algorithms, OpenSSL offers a built-in command, openssl speed. Using the following command, you can obtain the list of supported algorithms:

/opt/openssl# openssl list –cipher-commands
aes-128-cbc    aes-128-ecb    aes-192-cbc   aes-192-ecb
aes-256-cbc    aes-256-ecb    aria-128-cbc  aria-128-cfb
aria-128-cfb1  aria-128-cfb8  aria-128-ctr  aria-128-ecb
— snip —

In order to determine the performance of a specific algorithm, you need to call openssl speed ¡algorithm¿. As an example, to test the performance of an AES-128 block cipher in CBC mode, you need to call this:

/opt/openssl# openssl speed aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 149860669 aes-128-cbc’s in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 66115959 aes-128-cbc’s in 3.00s
— snip —
The ’numbers’ are in 1000s of bytes per second processed.
type          16 bytes    64 bytes    256 bytes  — snip —
aes-128-cbc  799256.90k  1410473.79k  1447774.12k  — snip —

So, to benchmark GCM against the other authenticated encryption schemes we have seen so far, we can call openssl speed with the desired algorithms. For simplicity, we will run the benchmarks on blocks of 8,192 bytes:

/opt/openssl# openssl speed -bytes 8192 -evp aes-128-gcm; openssl speed -bytes 8192 -evp chacha20-poly1305; openssl speed -bytes 8192 -evp aes-128-ccm; openssl speed -bytes 8192 -evp aes-128-ocb
— snip —
The ’numbers’ are in 1000s of bytes per second processed.
type          8192 bytes
AES-128-GCM    5585141.76k
— snip —
ChaCha20-Poly1305  2215840.43k
— snip —

AES-128-CCM    1337092.78k
— snip —
AES-128-OCB    5607677.95k

Table 16.1 summarizes the performance numbers for the four benchmarked authenticated encryption algorithms and the different block sizes that we obtained on our machine. Our comparison is for illustration purposes. If you repeat the experiment, your numbers will be different, but the relative performance of these algorithms should be roughly the same.

 Table 16.1: Comparison of the performance of authenticated encryption algorithms using 8,192-byte blocks

While our performance measurement described here is for illustration purposes (see [115] for a scientific treatment on GCM performance), we can still make several observations based on the results in Table 16.1:

• GCM is faster than CCM and ChaCha20-Poly1305
• ChaCha20-Poly1305 is faster than CCM
• OCB has a comparable speed to GCM (the reason OCB did not become mainstream is because after its introduction, two U.S. patents have been issued for OCB)

Therefore, we can conclude that TLS 1.3 implements the two fastest authenticated encryption schemes currently available (as we will see in Chapter 18, TLS Cipher Suites, GCM is mandatory to implement in TLS 1.3, and ChaCha20-Poly1305 is a so-called standby cipher that TLS 1.3 endpoints should support).

16.4 Summary

In this chapter, we studied GCM – the default, mandatory-to-implement authenticated encryption with additional data algorithm used in TLS 1.3. We covered the GCM design and working principles, and we discussed its security.

Moreover, we looked into GCM performance – and why the performance of cryptographic algorithms matters in general – and learned how to benchmark authenticated encryption algorithms covered in this book using OpenSSL.

In the next chapter, we will zoom out of technical and mathematical details and revisit the TLS Record protocol from a higher-level, conceptual perspective. The aim of the next chapter is to understand how the individual cryptographic mechanisms we covered so far fit together to ensure the confidentiality and integrity of data transmitted in TLS records.