What Is Perfect Forward Secrecy?

Perfect forward secrecy (PFS), also called simply forward secrecy, is a security property that keeps your past communications safe even if a long-term secret key is later stolen. It works by using fresh, temporary (ephemeral) keys for each session or message, so compromising one key does not unlock everything that came before.

The idea answers a chilling question: "If someone records all my encrypted traffic today and steals my key next year, can they read everything retroactively?" Without forward secrecy, the answer is often yes. With it, the answer is no — the keys that protected past messages were ephemeral and have already been deleted.

How forward secrecy works

The mechanism is ephemeral key exchange. Instead of encrypting everything under one long-lived private key, the two parties run a Diffie–Hellman exchange with temporary key pairs to derive a per-session (or per-message) key. Once that session ends, the ephemeral private keys are discarded and never written to disk. Later, even an attacker who obtains your long-term identity key cannot reconstruct the discarded ephemeral keys, and therefore cannot decrypt the recorded ciphertext.

In messaging, the strongest form pushes this to every single message. The Double Ratchet continuously derives new keys and deletes old ones, so forward secrecy holds not just between sessions but between individual messages.

Why perfect forward secrecy matters

Long-term keys leak in many ways: a seized or stolen device, a server breach, a coercive legal order, malware, or a careless backup. Without forward secrecy, any one of these events is retroactively catastrophic — every message ever sent becomes readable. With forward secrecy, the damage is contained to a narrow window, and often to nothing at all if the relevant ephemeral keys are already gone. It converts a single point of failure into thousands of tiny, expired ones.

Common misconceptions

• "Perfect means unbreakable." "Perfect" here is a specific technical property about past sessions, not a promise that nothing can ever be decrypted. Endpoint compromise still exposes messages currently stored in plaintext.
• "Any encrypted app has forward secrecy." Not necessarily. Some systems encrypt everything under a static key or store readable backups. Forward secrecy specifically requires ephemeral keys and deleting them.
• "Forward secrecy protects future messages after a hack." That is a related but different property called post-compromise security. Forward secrecy protects the past; the Double Ratchet adds protection for the future too.

Forward secrecy on the web (TLS)

Forward secrecy is not unique to messengers — you benefit from it every day on the web. Older HTTPS configurations used the server's long-term RSA key both to authenticate and to encrypt the session key, which meant that anyone who recorded the traffic and later obtained that one private key could decrypt every past session. Modern TLS (especially TLS 1.3) fixes this by using ephemeral Diffie–Hellman (ECDHE) key exchange for every connection, so each session gets a temporary key that is discarded afterward. Stealing the server's long-term key no longer unlocks recorded sessions. This shift, now the default across the web, is one of the largest practical deployments of forward secrecy in existence, and it is the same core idea — ephemeral keys, promptly deleted — that a secure messenger applies at the granularity of individual messages.

Where OSHI actually stands

Most pages that explain forward secrecy end by telling you the product has it. This one does not, because that would not be true of every OSHI conversation today. Here is the honest status, in the same detail we would want from someone else's security page.

What was fixed on 8 September 2026. In the v3 path, a responder started its sending chain from 32 zero bytes — a publicly derivable value rather than a secret. Any forward secrecy that direction of the session was supposed to provide did not hold. The fix landed on 2026-09-08 and ships in version 1.0.44.

What is still open, and is inherent. On the responder-first path, the initiator's very first message is derived from the X3DH handshake output alone, before any ratchet step has run. That first message does not get per-message forward secrecy. This is a property of the construction, not a bug to be fixed: the ratchet has nothing to ratchet from until the first round trip completes. The same is true of comparable protocols.

What that means for you. If your threat model assumes an adversary is recording your traffic now and may obtain a key later, do not assume today's OSHI session protects the backlog. Until v3 is the floor for the whole installed base, the correct summary is: forward secrecy is implemented, negotiated, and not yet universal.

OSHI needs no phone number, is end-to-end encrypted by default, and its source is public under the MIT license, so none of the above has to be taken on trust — it can be read.

Frequently Asked Questions