Key Management Is 90% of the Problem
Why Even Cryptography Experts Can’t Get Key Management Right
The world’s leading organization for cryptographic research just lost an encryption key and had to cancel their own election.
If the people who literally write the papers on cryptography can’t manage their keys, what chance does your engineering team have?
At the RSA conference this week, Whit Diffie (the “Diffie” in “Diffie-Hellman key exchange”) shared the anecdote from late last year. The International Association for Cryptologic Research (IACR) is the premier organization for advancing cryptography and the publisher of multiple journals in the field. Since about 2010 they’ve held elections for leadership positions using an open source cryptographic voting system called Helios. Helios ensures votes are cast anonymously, tallied accurately, and are tamper-proof.
But in late 2025, the IACR had to cancel and re-do their leadership election after losing the encryption key needed to get the results. Ouch!
The irony is thick
In this beautifully designed system used by the world’s leading experts in cryptography, the entire thing was undermined by that most critical and underappreciated problem: key management.
No matter how good the cryptography scheme, no matter how perfect the implementation, it always comes down to the keys.
XKCD nailed the spirit of this years ago:
The weakest link is rarely the algorithm. It’s the management of the keys and the intersection of keys with humans that produce most of the problems.
As an added interesting detail, the IACR didn’t exactly use a single key. They used a multi-party scheme that required three trustees who each held a part of the key to come together to decrypt the results. Two of the three had keys, the third trustee was unable to provide their part, and all of the data is now locked forever.
Going forward, IACR will use a two-of-three secret sharing scheme for better resiliency to this sort of thing.
Encryption is the simplest part
To developers, leveraging encryption seems easy. After all, there are lots of libraries that provide this functionality and you just have to call encrypt and decrypt functions. But this is misleading in so many ways.
For one thing, there are many decisions to be made from what algorithm and library to use, to sources of randomness, to the management of IVs. It’s easy to make poor choices and never know it. We’ve written on this a lot, but as a good example, check out our blog on MySQL encryption.
But although using cryptography comes with hidden pitfalls, that’s just the tip of the iceberg. You can’t encrypt or decrypt without keys, which means you also need to build out ways to create, store, protect, and share them.
How key management breaks down
Losing keys like in the IACR example is just one thing to defend against. There are many ways to screw up with keys. The requirements around them (and the systems interfacing them) get more complex as you add necessary functionality like key rotation and revocation. Very quickly, instead of managing one key, you have different keys for different points in time with varying access controls, possibly different algorithms or key sizes, and more. Then if you get into customer managed or customer held keys, the number of pitfalls grows even more.
We’ve talked about this before, but key management is where the incredible data security offered by cryptography goes to hell. It’s also why we often rail against transparent encryption where on a running server the “encryption at rest” doesn’t actually protect the data unless someone physically steals a hard drive.
Consider end-to-end encryption (E2EE): how do you allow someone to use multiple devices? Perhaps you derive the key from a password and recreate it on each device. But then what happens if the user forgets their password? Recovery mechanisms often mean the service provider can access the data and it’s no longer truly E2EE.
These are difficult challenges to solve to make an application secure while staying usable and resilient to human failures. For E2EE, our Data Control Platform is a good approach, and we discussed other E2EE pitfalls with pointed examples in another recent blog.
Why 90% of what we build is key orchestration
IronCore doesn’t store keys or even provide software that stores keys. But probably 90% of what we do is what I call “key orchestration.”
Our SaaS Shield platform manages layers of keys (envelopes, if you will), but the master keys go to your and/or your customers’ key management systems backed by hardware security modules. IronCore never sees any keys or data of customers. To be highly performant, resilient, and secure, a lot of work has gone into the key management edge cases and the machinery needed to make these things work well over the long term.
Don’t build the hardest part yourself
Don’t underestimate the challenges of doing it yourself or the incredible accelerating power of using a well-built application-layer encryption platform. If you’re interested in data protection for cloud applications, or in meaningfully protecting data while it stays searchable, please reach out to us.
