Forward Secrecy
Also known as: perfect forward secrecy, PFS, forward secrecy in messaging, forward security
Forward secrecy is the property that compromising your long-term keys today cannot decrypt messages you sent or received in the past. In messaging it is achieved by deriving a fresh, single-use key for every message and deleting it immediately after, so an attacker who seizes a device captures only the keys still live at that moment, not the conversation's history.
In a messenger, forward secrecy is what stops a single bad day from becoming a total catastrophe. The contrast that makes it click is PGP email: encrypt a decade of mail to one PGP key, and if that key ever leaks, every message ever sent to it becomes readable at once. One compromise, total exposure. Forward secrecy is the opposite design — the window of exposure for any single key compromise is exactly one message.
Modern messengers get this from the Double Ratchet. Two mechanisms work together. First, the symmetric ratchet advances a chain key through a one-way function (HMAC-SHA256) for each message and derives a use-once message key. Because the function is one-way, holding chain_key[n+1] reveals nothing about chain_key[n] or any earlier message key. Second, the DH ratchet mixes a fresh Diffie-Hellman exchange into the keys every time the conversation changes direction.
The catch most people miss: forward secrecy is only as strong as your deletion. If a "deleted" key lingers in RAM, swap, or a disk backup, the guarantee evaporates. That is why serious implementations zero key bytes with zeroize, lock pages out of swap, and never write message keys to disk. It also explains why automatic cloud backups quietly undermine forward secrecy.
How it works
Per message, the sender derives message_key = HMAC-SHA256(chain_key, 0x01), encrypts, then overwrites the message key in memory. The chain key advances via chain_key' = HMAC-SHA256(chain_key, 0x02), a one-way step.
Forward direction is trivial (chain_key[n] → chain_key[n+1]); the backward direction (chain_key[n+1] → chain_key[n]) is infeasible because HMAC-SHA256 is a pseudorandom function and cannot be inverted.
When the other party replies, a DH ratchet step runs a fresh X25519 exchange and HKDFs it with the root key to produce a brand-new chain. The old root key and old DH private key are deleted. This is break-in recovery: even an attacker who grabbed the current state cannot derive the post-reply keys, because they never saw the new random DH private key.
How RVNT uses Forward Secrecy
RVNT derives a fresh single-use message key per message and zeros it with Rust's zeroize crate (volatile writes plus a compiler barrier so the wipe is not optimized away); on supported platforms key pages are mlock'd out of swap. Message keys never touch disk, and stored ratchet state lives in a SQLCipher database with secure_delete on. RVNT creates no cloud backups, precisely to preserve this guarantee. See Forward Secrecy.
Frequently asked questions
What is forward secrecy in messaging, in plain terms?
It means stealing your keys today cannot unlock the messages you already sent. Apps achieve it by using a different throwaway key for every message and erasing each one right after, so a captured device only yields the few keys still in use, never the whole history.
How is forward secrecy different from end-to-end encryption?
End-to-end encryption ensures only you and your contact can read a message. Forward secrecy adds a time guarantee on top: even if your keys are later stolen, past messages stay sealed. You can have end-to-end encryption without forward secrecy — PGP email is the classic example.
Does forward secrecy protect my message history if my phone is seized?
It protects messages whose keys have already been deleted and ratcheted past — those cannot be recovered. It does not protect plaintext your app still has stored on the device. That is what the encrypted local database, PIN unlock, and panic-wipe are for.
Every definition here describes something RVNT actually ships — a post-quantum, end-to-end-encrypted, peer-to-peer messenger with no phone number and no servers.