AES-GCM: The Encryption Workhorse Keeping Your Data Safe (And Why You Should Care)

Every single time you visit a website over HTTPS, decrypt that encrypted hard drive, or send a message on WhatsApp, there's a good chance your data is being protected by something called AES-GCM.

Most developers either never need to know what it's doing or know it as "that thing you pick when the security docs tell you to." But here's the thing - understanding how AES-GCM actually works isn't just academic waffling. Get it wrong, and you could be leaving massive security holes in your applications.

We've spent years building secure systems, and we've seen what happens when teams treat encryption as a black box or afterthought.

AES: The Engine Under the Bonnet

AES (Advanced Encryption Standard) is what we call a block cipher. Picture it like this: AES takes 128 bits of data (that's 16 bytes) and transforms it into complete gibberish using a secret key. That key can be 128, 192, or 256 bits long - the longer, the more secure.

AES is absolutely brilliant. It's been battle-tested for decades without any practical breaks, it's fast as lightning (especially on modern Intel and AMD chips), and it's secure enough that governments trust it with classified data.

But here's the catch: AES only encrypts one tiny block at a time. Real-world data - your files, messages, web requests - are way longer than 16 bytes. So we need a way to chain these AES operations together.

Modes of Operation: The Good, The Bad, and The Dangerous

This is where modes of operation come in. Think of them as different strategies for using AES on longer data:

ECB (Electronic CodeBook) - Don't use this. Ever. Each block gets encrypted independently, which means patterns in your original data show up in the encrypted version. It's like putting a transparent sheet over your data instead of proper encryption.

CBC (Cipher Block Chaining) - Better, but fiddly. It links blocks together for security, but if your data isn't exactly divisible by 16 bytes, you need padding. Plus, you need separate integrity checks.

CTR (Counter Mode) - Now we're talking. This turns AES from a block cipher into a stream cipher. It encrypts a counter value and XORs it with your data. Works on any length data, no padding needed, and you can process multiple blocks in parallel.

CTR mode is mint for performance, but it has one massive problem: it only gives you confidentiality, not integrity.

What does that mean? An attacker could flip bits in your encrypted data to modify it, and you'd have no idea. Imagine someone flipping bits in an encrypted bank transfer to change the destination account. You wouldn't know until it's too late.

Enter GCM: The Hero We Needed

GCM (Galois Counter Mode) takes CTR mode and adds the missing piece: an integrity check through something called an authentication tag. This whole setup is known as AEAD - Authenticated Encryption with Associated Data.

Here's what happens:

1. Data gets encrypted using CTR mode (fast and parallel)
2. A tag gets computed using mathematical wizardry over the encrypted data and any associated data you want authenticated but not encrypted (like headers)
3. You get back the encrypted data plus the authentication tag

When someone tries to decrypt this, the tag gets checked first. If anything's been tampered with, the decryption fails completely. Now you've got both confidentiality AND integrity.

As a bonus, GCM also helps prevent timing attacks and other sneaky side-channel attacks that plague some encryption schemes.

Where It All Goes Wrong: Security Pitfalls That'll Keep You Up at Night

Even with all these safety features, AES-GCM can still bite you if you're not careful:

1. Nonce Reuse: The Kiss of Death

Every encryption operation needs a unique "number used once" (nonce). Use the same nonce twice with the same key, and you've basically handed attackers the keys to the kingdom. They can:

• Launch replay attacks
• Extract information about your original data
• Completely break message integrity

I've seen production systems go down because someone thought generating random nonces was "too expensive." Don't be that person.

2. Tag Truncation: Death by a Thousand Cuts

Some developers think they're being clever by truncating the authentication tag to save space. "What's the harm in using 10 bytes instead of 16?"

The harm is you've just opened the door to forgery attacks and made side-channel attacks much easier. Use the full tag length.

3. Rolling Your Own Crypto: Professional Suicide

Please, for the love of all that's holy, don't implement cryptographic libraries yourself. These libraries have been poked, prodded, and tested by thousands of security researchers. Your homegrown implementation hasn't.

AES-GCM in the Wild: A Java Example

Here's how you actually use AES-GCM properly in Java:

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import java.security.SecureRandom;
import java.util.Base64;
 
public class AESGCMExample {
    public static void main(String[] args) throws Exception {
        // Generate a proper 256-bit AES key
        KeyGenerator keyGen = KeyGenerator.getInstance("AES");
        keyGen.init(256);
        SecretKey key = keyGen.generateKey();
 
        // Generate a 96-bit nonce (12 bytes)
        byte[] nonce = new byte[12];
        SecureRandom random = new SecureRandom();
        random.nextBytes(nonce);
 
        String plaintext = "Hello, AES-GCM!";
        byte[] aad = "authenticated but not encrypted".getBytes();
 
        // Encrypt
        Cipher encryptCipher = Cipher.getInstance("AES/GCM/NoPadding");
        GCMParameterSpec gcmSpec = new GCMParameterSpec(128, nonce); // 128-bit tag
        encryptCipher.init(Cipher.ENCRYPT_MODE, key, gcmSpec);
        encryptCipher.updateAAD(aad);
        byte[] ciphertext = encryptCipher.doFinal(plaintext.getBytes());
 
        // Decrypt
        Cipher decryptCipher = Cipher.getInstance("AES/GCM/NoPadding");
        decryptCipher.init(Cipher.DECRYPT_MODE, key, gcmSpec);
        decryptCipher.updateAAD(aad);
        byte[] decrypted = decryptCipher.doFinal(ciphertext);
 
        System.out.println("Ciphertext (Base64): " + Base64.getEncoder().encodeToString(ciphertext));
        System.out.println("Decrypted: " + new String(decrypted));
    }
}

Key points from this code:

• Use SecureRandom for nonces - never hardcode them
• 256-bit keys are the gold standard these days
• 12-byte nonces are standard for GCM
• Full 128-bit authentication tags - don't truncate
• Associated data can include headers or metadata you want authenticated but not encrypted

The Reality Check

AES-GCM has become the workhorse of modern encryption because it solves real problems that software engineers face every day. It's fast, secure, and gives you both confidentiality and integrity in one go.

Every time you browse the web, send a secure message, or unlock encrypted data, AES-GCM is quietly doing its job behind the scenes. It's protecting billions of transactions, messages, and files every single day.

But like any powerful tool, it requires respect. Use it properly, and it'll keep your data safer than Fort Knox. Get it wrong, and you might as well be storing passwords in plain text.

The Manchester tech scene is buzzing with companies building secure, scalable applications. Understanding the tools that protect our digital lives isn't just useful - it's essential for any developer who takes their craft seriously.

Want to dive deeper? Check out these brilliant resources:

• AES explained (Advanced Encryption Standard) - Computerphile
• AES GCM (Advanced Encryption Standard in Galois Counter Mode) - Computerphile