Ratchet crypto and forward secrecy: a simple primer
published: 28 Jul 2025
Intro
Around two years ago, I had an interesting conversation with my partner. She was talking about how annoying Matrix servers are to operate at scale, mainly due to the amount of data they accumulate.
“Matrix stores most of the messages on the server instead of the client,” she explained, “so it can start to add up to a lot.”
“Wait what?” I said, confused.
“Yeah, it can go up to a few hundred gigabytes.”
“No but like it uses ratchet crypto, right? It makes no sense to store messages on the server because the clients won’t be able to decrypt them anymore.”
“Oh yeah, it just keeps the old keys.”
“It does what???”
And so I felt inspired to try to write a little explanation on how ratchet cryptography works, and why this conversation confused me; and then I forgot about it and left it lying around for a while. So while I feel like the air around Matrix has shifted quite a bit recently, and a lot of other, much more thorough writing on Matrix crypto has come out since then, I think it’s still an interesting topic to talk about and I decided to publish this after all. But please note that I am not an expert; the full extent of my formal qualification on the subject is a cryptography module I took for fun at uni. If you find anything that’s wrong, corrections are welcome.
Why you want forward secrecy
To understand ratchet cryptography, let’s first imagine a messenger without it. Let’s say that you and your friend want to talk in a way that really is going go stay secret, even in the face of a reasonably powerful adversary. In classic cryptographer tradition, we’ll call her Eve – just keep in mind that Eve doesn’t necessarily have to be a single person. She could also be an institution, agency, or other such thing.
You use a messenger with a simple cryptographic protocol. It’s got a secret key that’s shared between the both of you and that’s what it uses to encrypt and decrypt messages.1 Only people with the key can read, no one has the key but you and your friend, so no one else can read – not even Eve!
But then, an incident: Eve somehow gets access to your encryption keys. Maybe she dresses up as a police officer and persuades you to give up the key; perhaps she sneakily steals it for your password manager in a moment of inattention, or snatches your unlocked phone out of your hands!
You do a damage assessment. Thanks to auto-deletion, there aren’t that many messages she could have seen, and the really spicy stuff is weeks ago already. You and your friend will have to exchange a new key now, but otherwise it seems you got off easy. Everything should be okay, but something keeps nagging the back of your mind...
And your worries are not unfounded, because Eve is a crafty entity. Somehow or other, she’d already had access to your encrypted messages. Some whisper that she is listening in at the big Internet nodes and stores away anything that piques her interest, even stuff she can’t read. But maybe she also just got into the server that exchanges your messages. When she did all this, your messages were still unreadable to her, but now –
Now she can read all of them, every last one: For she has your key now, and as you decrypted with it so now she does too.
Your messaging protocol was lacking a property called forward secrecy, which is a fancy word that means that if a message is secret now, it will stay secret going into the future. You can’t retroactively decrypt it, like Eve just did. Let’s try making something better.
How you get forward secrecy
So, keeping your old keys around was kind of a mistake. But how do you make new keys? You might not want to jump through all the hoops of key exchange for every new message you send.
Turns out, computers have something called hashes. A hash is something that you can hand data to, and it munches that data up until it’s completely unrecognizable and spits the resulting mess back out. The important bit is that if you put in the same thing, you will always get the same result; but everything gets so mangled that there’s no way to reverse the process.
So, you use this to make a new messaging protocol: every time you send a message, you put the key through the hash. Every time your friend receives a message, they put the key through the hash too. And then, you both delete the old keys.2
So now, when Eve snatches away your phone, or you lose keys in some other way, your old messages are safe even if someone has stored an encrypted copy of them. Because the hash function only goes one way, you can derive newer keys from older keys, but not the other way around. All of the keys you have ever used in the past are irretrievably lost. That’s why it’s called a ratchet; it only goes one way.3
Conclusion
Having read the above, you may now understand why I was confused at learning that Matrix kept old keys. They specifically designed a ratchet protocol for group chats (megolm), and yet also designed it in such a way that one of the fundamental motivations for using a ratchet protocol (namely, not having to keep old keys) was obviated.
To be clear, it’s not as if this was some huge secret or anything. The protocol spec clearly and specifically addresses this point, and there are indeed benefits to the ratchet even in Megolm. Members that are new to a particular channel, for example, will not be able to decrypt messages from before they joined unless the old keys are shared with them. The spec also mentions that clients may offer functionality to throw away old keys, and become unable to read the messages they correspond to.
But it still all feels a little haphazard. The protocols feel clearly inspired by the now industry standard Signal protocol. And yet there is a large difference between the security guaranteed by an actual implementation of said protocol, and what Matrix does. I think that’s important to keep in mind.
And I would like to make a broader point here, too, even if it’s not all that relevant to the Megolm spec in particular. People often say “don’t roll your own crypto”. The reason they say that is that crypto often is a little bit like witchcraft: You might think you’re doing all the right motions and following the instructions exactly, but if you miss one small element that you didn’t even know was important, or the setting is just a little bit off, things can go wrong. Using a ratchet is not beneficial in and of itself. The security guarantees provided by it depend on the larger context within which it is used.
Take care.
Footnotes
- For this, we’re going to ignore how you exchanged the key. Maybe you met up in person and your friend whispered it into your ear. Or, more likely, you used one of those algorithms that lets you establish a secret key even if you can’t talk in secret. ↩
- In real life, there is a lot of my complexity to this. Notably, you might keep the old keys for a little bit longer just in case some messages get delivered out of order. But the basic principle holds. ↩
- You might ask what happens to messages after a key compromise. When someone has a copy of your key, they can ratchet it forward just like you and your friend. This means that while all messages sent before a key compromise are safe, messages sent afterwards are not. There are more advanced protocols, like signal’s double ratchet, that continuously perform new key exchanges in the background. This way, the system can automatically heal after a compromise, and eventually the messages may be safe again, even without manual intervention. ↩