When encryption works perfectly and still fails

Encryption underpins the security of every software system with more than one user. Modern cryptography enables us to send and receive messages over the literal air, processed by who-knows-how-many-people’s hardware, with confidence that no one can listen in or tamper with those messages. 

So, security is solved, right?

Obviously not. Here’s a quick outline on why, exactly:

• The cryptography threats people talk about

• The big problem, a.k.a. Waltz’s folly

• Kissner’s law: key management problems are harder than you think

The cryptography threats people talk about

There are a few flavors of cryptography threats that are popular in the public sphere. 

Mathematically, asymmetric cryptography is based on problems that are hard if you don’t know the inputs (keys), like prime factorization. That means if there is some breakthrough in these problems, like discovering P = NP or using a quantum algorithm (with a corresponding quantum computer), then we’ll be scrambling to rewrite all cryptography code.

There’s also a certain romantic appeal for cryptanalysis. Think World War II era - British intelligence agents cracked the Enigma machine used to encrypt German military communications with a combination of code-breaking and good old-fashioned espionage. Geniuses like Alan Turing spent late nights poring over intercepted printouts to figure out the underlying secrets. Glamorous, right?

Image from The Imitation Game (2014), a biopic of Alan Turing

Moving to the implementation level, side channel attacks are a hot topic. In Bleichenbacker’s padding oracle attack, you painstakingly discover an encryption key one bit at a time, by interpreting the error messages you get back when you guess wrong (one reason why error messages these days are so useless - to prevent this leakage). In speculative execution attacks like Spectre or Meltdown, you use the timing of a performance optimization to exfiltrate private data. There are even attacks like Rowhammer where you use the physical characteristics of RAM circuits to break through security protections. 

These technical challenges are a cat-and-mouse game between attackers and defenders, with active research and real-world action. Yet none of these cryptography threats are as relevant as the true threat: accidentally adding someone to the wrong group chat.

The big problem, a.k.a. Waltz’s folly

In case you missed it, National Security Advisor Mike Waltz accidentally added journalist Jeffrey Goldberg to a group chat in March 2025, exposing sensitive details of US military actions in Yemen. They used the encrypted messaging app Signal, which has rock-solid cryptography: end-to-end encryption, perfect forward secrecy, confidential computing to prevent leaking metadata server-side, and even using quantum-resistant cryptography to defend against future threats. 

The only (cryptographic) problem is, Waltz invited the wrong guy. And that gave Goldberg the keys needed to read all of those messages.

Screenshot of the group chat, via The Atlantic.

This kind of failure happens all the time. Have you ever forwarded an email to the wrong person? Or put a file in the wrong folder? Anyone is capable of disregarding military operational security and using unapproved tools adding someone to the wrong group chat. Once you grant someone access, they get the encryption keys and can decrypt everything for their own eyes to read.

That’s a fundamental security issue that no amount of cryptography can ever fix. The encryption keys and protocol worked exactly as they were intended to. But the keys were handed to the wrong person. 

Kissner’s law and its implications

I love this framing from Lea Kissner (co-creator of Google’s Zanzibar authorization system and current LinkedIn CISO):

Lea Kissner, via Twitter

In the spirit of associating this idea with a more-famous name, I think of it as Kissner’s law - 

Kissner’s law: Cryptography converts many problems into key management problems, and key management problems are way harder than you think. 

Modern cryptography has come a long way from Julius Caesar (LUPAUJ? R BLZXDH EYWQ ZNL!) - improvements in algorithms, key sizes, and protocols have made it easier than ever to protect the bits and bytes that make up our digital lives. Want to restrict access to something? Just lock it behind the appropriate encryption key. It’s an incredibly powerful tool.

Managing those keys is an entirely different world, and one that I’d argue is less mature. Consider the following key management questions:

• How do I know your identity before I give you a key?

• Who has the power to generate a key?

• What if a key leaks? How do I revoke or rotate a key without breaking the whole system?

Today, I can show you a flashy demo to scrape an encryption key out of server memory and use it to unlock the database! Publicly-known breaches often start from a much more boring exploit: phishing some employee who already has access to the database. In both cases, it’s not about attacking the cryptography; it’s about exploiting the key management.

I’m not sure we’ll ever get to a world where security teams can confidently publish “key management right answers”, like Latacora does for cryptography. Key management decisions will force certain aspects of the user experience, and that will need to vary depending on the application itself. 

So the next time someone says, “Don’t worry, it’s encrypted,” ask them the real question:

Who manages the keys?