Why Is AES GCM Good (and Not So Good) for Cybersecurity …

We live in a strange world of cybersecurity. An auditor might ask a company if they encrypt their data? And the company may reply that…

Why Is AES GCM Good (and Not So Good) for Cybersecurity …

Spotify Podcast [here]. Apple Podcast [here]. Audible [here]

We live in a strange world of cybersecurity. An auditor might ask a company if they encrypt their data? And the company may reply that they do, and so the auditor would tick that off. But encryption does not just involve the privacy of data; it also involves integrity checking and setting up digital trust. Along with this, there are many ways to implement methods, including key derivation, public key integration, hashing methods, and encryption modes. And, so, last week I outlined how some AES modes can be easily modified:

And so, someone asked me why I recommended GCM (Galois Counter Mode)? Well, GCM integrates integrity into the cipher. It is built on CTR (Counter) mode and is a stream cipher. This makes it fast. Along with this, we can add additional data into the ciphertext — and which defends against playback attacks. At the core of this is the Galois Message Authentication Code (GMAC).

What’s MAC?

A message authentication code (MAC) can be used to verify the integrity and authentication of a message. One of the most popular MAC methods is HMAC (hash-based message authentication code) [here]. It involves hashing the message with a secret key and thus differs from standard hashing, which is purely a one-way function. Figure 1 outlines the operation, where the message to be sent is converted with a secret key and the hashing function to an HMAC code. This is then sent with the message.

On receipt, the receiver recalculates the HMAC code from the same secret key and the message and checks it against the received version. If they match, it validates both the sender and the message. If Eve will not be able to create a valid MAC if she does not have the secret key. Along with this, if she flips bits in the ciphertext, it will not match with the MAC, and Alice will reject it.

Figure 1: HMAC

What MACs are there?

There are many MACs around, including HMAC, GMAC, CMAC, Blake2bmac, Blake2smac, KMAC128 and KMAC256. The following is an example of a GMAC (using a stream mode, such as with GCM) [here]:

openssl mac -cipher AES-128-GCM -macopt hexkey:77A77FAF290C1FA30C683DF16BA7A77B -in 1.txt  GMAC
740DDAFDB2008F4E3C7D10B9141A84DF

The following is an example of a CMAC (used with block mode ciphers):

openssl mac -cipher AES-128-CBC -macopt hexkey:77A77FAF290C1FA30C683DF16BA7A77B -in 1.txt  CMAC
8CDBB6E42ED45C8A98328ADC739D3E41

For a 256-bit key with AES-256-CBC:

openssl mac -cipher AES-256-CBC -macopt hexkey:77A77FAF290C1FA30C683DF16BA7A77B77A77FAF290C1FA30C683DF16BA7A77B -in 1.txt  CMAC
12F029BB51AC78D457DAF414A25A57EE

GHASH

GCM (Galois Counter Mode) is an encryption method with authentication for symmetric key encryption. It is fast and allows for parallel processing. The GF(2¹²⁸) ) field is used (x¹²⁸+x⁷+x²+x+1). An authentication tag is created by inputting the data into a GHASH function and encrypting the result. This function is GHASH(H,A,C)=𝑋_{m+n+1} and where H=E_k(0,128) is the Hash Key —and which all 128 bits of zero, A defines the authenticated data, C defines the ciphertext, m related to the number of blocks, and n the number of blocks in C (rounded up). and the variable Xi for i = 0, …, m + n + 1 i. A sample run is [here]:

== GHash==
Key: "0123456789ABCDEF"
Bytes: "0123456789ABCDEF1011"

MAC: 39076d2a3477c873f4ab55e05d4e7ca4

MAC: OQdtKjR3yHP0q1XgXU58pA==

The downside? Reuse IV and Weaker IV

GCM (GHASH) is a weaker MAC than HMAC, and where GHASH only provides a maximum 128-bit authentication tag. With HMAC-SHA-256, we can support a 256-bit authentication tag. Although it is extremely difficult to mimic a GHASH with different data, it is certainly feasible. GCM mode also typically uses a smaller IV than other modes — with 96 bits being typical. There is thus a higher chance of an IV collision than when a 128-bit IV is used.

GCM is a stream cipher mode it is open to a reuse IV attack. With this, the IV (Initialization Vector) of the cipher is the same for two cipher messages. We can then XOR to the two cypher streams together to reveal the cipher stream key (K). We can then reveal the plaintext by XOR-ing any cipher stream with K. In the following, we have a reuse of the IV [here]:

Message 1: Hello
Message 2: hello
Cipher 1: 5fcbe7378cf8c68b82a2b8d705354e8d6c0502cef2
Cipher 2: 7fcbe7378c2b87a5dfb2803d4fcaca8d5cde86dbfa
Key: 30313233343536373839414243444546
Nonce: 303132333435363738394142
XOR: 2000000000d3412e5d1038ea4aff840030db841508
Decrypted: Hello
Decrypted: hello

An example of this happened recently with Samsung phones:

Conclusions

GCM is a great deal better than most modes, but it is not perfect. Nonce reuse is a particular problem. GHASH is too weaker than HMAC. But, overall, it’s great and highly recommended. But, don’t dismiss using CTR mode with HMAC — as it will be a strong implementation, In SIV mode, too, we overcome the IV reuse problem. So, GCM is generally better than CBC and ECB, but not as good as CTR with HMAC and SIV mode.

Here are some of the other AEAD modes:

https://asecuritysite.com/aes/hazauth

References

[1] Shakevsky, A., Ronen, E., & Wool, A. (2022). Trust Dies in Darkness: Shedding Light on Samsung’s TrustZone Keymaster Design. Cryptology ePrint Archive.