Glossary · Encryption

Forward secrecy

Forward secrecy is the property that compromising a key today does not allow the messages sent before that compromise to be decrypted, because the keys that protected them have already been destroyed.

Open betaThe platform is being built in the open, so parts of it are not there yet, behaviour changes between releases, and no availability figure is committed while it is in beta. What is still being built.

Also called

Perfect forward secrecy · PFS

What Forward secrecy means

Without forward secrecy, a single long-lived key protects a whole conversation, and anybody who eventually obtains it — by seizing a device, by compelling a provider, or by breaking in — retrieves the entire history at once. This makes stored ciphertext permanently valuable to an attacker, which is precisely the assumption behind harvest-now-decrypt-later collection.

Forward secrecy is achieved by deriving a fresh key for each message or each short interval from the previous one, in a direction that cannot be reversed, and deleting the old one. The security therefore depends on deletion actually happening on the device, which is why forward secrecy is a property of an implementation as much as of a protocol.

It is worth being precise about what forward secrecy does not do. It does not protect messages sent after a compromise, it does not protect content that a recipient has chosen to back up in plaintext, and it does not protect metadata. Its scope is the past, and only the past.

How Enclessa uses it

Enclessa gets forward secrecy from MLS itself rather than from a policy: every epoch change ratchets the group key forwards and the previous secret is discarded. This applies to end-to-end encrypted direct messages. Managed channels do not have it, because the server holds a key by design so that search and export can work — which is the trade the room mode makes explicit at the moment a room is created.

Where Forward secrecy is specified

RFC 9420 § 2 — forward secrecy and post-compromise security

Related terms

MLS (RFC 9420)MLS, or Messaging Layer Security, is the IETF standard published as RFC 9420 for end-to-end encrypted group messaging, designed so that adding or removing a member costs work proportional to the logarithm of the group size rather than to the group size itself.Read the entry Post-compromise securityPost-compromise security is the property that a conversation heals after a device is compromised, so that once the compromised device is removed and the group re-keys, the attacker who held its keys can no longer read new messages.Read the entry End-to-end encryptionEnd-to-end encryption is a design in which a message is encrypted on the sending device and decrypted only on the receiving devices, so that the server carrying it holds no key that can open it.Read the entry Room modeA room mode is the fixed property of a conversation that decides whether the server can read its contents, chosen when the room is created and never changed afterwards.Read the entry OpenMLSOpenMLS is an open-source implementation of the MLS protocol written in Rust, developed in the open by contributors from Phoenix R&D, Wire and Cryspen, and subjected to external security review.Read the entry

Read further

The security page explains how Enclessa protects data and which certifications it does not hold. The trust centre covers the processing agreement, the subprocessors and the residency position. The FAQ answers the questions buyers ask most often.

Encrypted collaboration, hosted in Europe.

Create a workspace in a couple of minutes. It is yours at your-team.enclessa.app, hosted in the European Union, with encrypted direct messages from the first one you send.

Create your workspace See pricing

Open beta. Free plan, no payment card to start.