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.

How OSHI provides forward secrecy

OSHI delivers forward secrecy by giving every message its own ephemeral key. Its Double Ratchet over X25519 continually derives fresh AES-256-GCM keys and discards used ones, so a key compromised tomorrow cannot decrypt the messages you send today. Because OSHI needs no phone number and is end-to-end encrypted by default, and its source is public under the MIT license, this property is both built in and verifiable.

Frequently Asked Questions