Media Den

How Two Belgian Cryptographers Changed the Way the World Keeps Secrets

April 2026 · Privacy Advancements Series

A huge share of what you do online is protected by a single algorithm. Secure websites, encrypted cloud storage, private messaging apps: much of it traces back to AES-256-GCM. Most people have never heard of it. Here's the story of how it came to be.

The Standard That Was Dying

In 1977, the United States government standardized an encryption algorithm called DES (the Data Encryption Standard). For almost two decades, it was the backbone of secure digital communication. Banks used it. Governments used it. It was everywhere.

Then computers got faster. By the late 1990s, purpose-built hardware could crack a DES-encrypted message within days; in 1998, the EFF's "Deep Crack" machine solved a public challenge in about 56 hours, and by early 1999, the same hardware combined with a volunteer distributed network cracked another in just 22 hours.^[10] The algorithm's 56-bit key, once considered untouchable, had become a liability. The US government needed a replacement, and they needed it to last.

In 1997, the National Institute of Standards and Technology (NIST) did something unusual: they put out an open call to the entire world.^[1] Anyone (academic, corporate, or independent) could submit a candidate to become the new global encryption standard. The submissions would be evaluated publicly, scrutinized by cryptographers everywhere, and the best one would win.

The Race

Fifteen teams entered. The favourites were formidable: IBM submitted MARS. RSA Security submitted RC6. Counterpane Systems (led by the legendary cryptographer Bruce Schneier) submitted Twofish. A joint team from England, Israel, and Denmark submitted Serpent.^[2]

And then there were two Belgian academics from a university in Leuven no one outside of cryptography had heard of.

Joan Daemen and Vincent Rijmen had been working on encryption algorithms since the early 1990s. They named their submission after themselves: Rijndael, a portmanteau of Rijmen and Daemen. Their entry was elegant, fast, and required remarkably little memory, a crucial advantage in a world where encryption needed to run on everything from servers to smart cards.

NIST held three public conferences over three years, inviting cryptographers from around the world to try to find weaknesses in each submission. On October 2, 2000, they announced the winner: Rijndael. On November 26, 2001, it was officially standardized as the Advanced Encryption Standard (AES).^[3]

Why 256 Bits?

AES supports three key sizes: 128, 192, and 256 bits. That's the number of bits in the secret key used to encrypt and decrypt data. More bits means more possible key combinations, which means a brute-force attack takes longer, exponentially longer.

At 128 bits, there are more possible keys than there are atoms in the observable universe. So why bother with 256?

The answer is quantum computing. NIST's 1997 requirements explicitly called for an algorithm that could withstand future advances in computing, including quantum computers.^[1] A quantum algorithm called Grover's search effectively cuts a key's strength in half: a 128-bit key becomes 64-bit effective security, which a sufficiently powerful quantum computer could eventually crack. A 256-bit key becomes 128-bit effective security, which remains safe even against quantum attacks.

In 2001, practical quantum computers were science fiction. Daemen and Rijmen built for a threat that didn't yet exist. Today, the NSA approves AES-256 for encrypting top-secret government data.^[4]

Encryption Wasn't Enough

AES solved the confidentiality problem: only someone with the key could read the message. But encryption alone doesn't answer a different question: was the message tampered with?

Earlier encryption modes, including common ones like CBC (Cipher Block Chaining), couldn't detect if an attacker had modified the ciphertext in transit. They'd encrypt cleanly and decrypt cleanly, and you'd have no idea the data had been altered. Attackers learned to exploit this in a class of attacks called padding oracle attacks, which could sometimes allow decryption without ever knowing the key.

Confidentiality and integrity turned out to be two separate problems, and for years they were solved separately, and often badly.

Enter GCM, and a 19-Year-Old Who Died in a Duel

In 2004, David McGrew at Cisco and security researcher John Viega proposed a new mode of operation for AES called GCM (Galois/Counter Mode).^[5] It solved both problems at once.

GCM combines AES's stream encryption with an authentication mechanism based on mathematics developed by Évariste Galois, a French prodigy who made foundational contributions to abstract algebra before being killed in a duel in 1832 at the age of 20.^[9] The algebra he invented — Galois field theory — provides a way to produce an authentication tag that acts like a tamper seal on the ciphertext. If a single bit of the encrypted data is changed, the tag won't verify, and the decryption will fail.

This combination (encryption plus authentication in a single pass) is called Authenticated Encryption with Associated Data (AEAD). It was a conceptual breakthrough: instead of bolting security properties together and hoping developers did it correctly, AEAD made the secure approach the default. NIST standardized GCM in 2007.^[6]

The Standard the Internet Runs On

Today, AES-256-GCM is woven into the fabric of the modern internet.

TLS 1.3, which secures most modern HTTPS connections, requires AEAD ciphers, mandating both AES-128-GCM and AES-256-GCM as supported cipher suites.^[7] Many major services, including iCloud and Google Drive, use AES-256 for data at rest. Apple Silicon chips include hardware acceleration for AES, making encryption fast enough that you never notice it happening.

The One Rule You Can't Break

AES-256-GCM has one critical requirement: each encryption must use a unique nonce (a number used exactly once per key). If the same nonce is ever reused with the same key, the entire security of the scheme unravels. An attacker who obtains two ciphertexts encrypted with the same key and nonce can recover the plaintext of both messages, and potentially the authentication key itself, allowing them to forge new ciphertexts.

A 2016 study found 184 public HTTPS servers in the wild actively repeating nonces.^[8] It sounds like an easy mistake to avoid, but at scale (millions of encrypted files, connections, or messages) it requires careful engineering: counter-based nonce generation, per-file key derivation, or regular key rotation.

Well-built applications handle this transparently. You shouldn't have to think about it. But it's worth knowing the requirement exists, because it's why good cryptographic engineering matters.