OSL

Early access. OSL is being built toward its v1 launch, so some of what you see here is still being finished.

See what works today

How OSL works

The cryptography behind OSL, explained without needing a crypto background.

The basic idea #

OSL encrypts a supported message before the connected service receives it. When you send, OSL transforms the message into random-looking bytes called ciphertext. The service delivers that sealed carrier. The recipient's copy of OSL transforms it back into the original message.

Think of it like sending a sealed letter through the mail. The delivery service handles the envelope but cannot read its contents.

The cryptography #

OSL uses end-to-end encryption with a post-quantum hybrid. The building blocks:

  • X25519: a modern elliptic-curve key-exchange algorithm. It is battle-tested and used by Signal, WireGuard, and most contemporary secure-messaging systems.
  • ML-KEM-768: a post-quantum key-encapsulation mechanism standardized by NIST in 2024. It is designed to resist attacks from quantum computers that don't exist yet but might.
  • Per-message hybrid sealing: direct messages are sealed to the recipient's published X25519 and ML-KEM-768 keys with a fresh ephemeral key for every message, so each message stands on its own. Beta — this is what the code does today. Two limits worth stating plainly: it protects the contents of a message against a future quantum computer, not identity verification, which is still classical; and sender attribution is an open security finding, so "who sent this" is not yet a cryptographic answer.
  • Group chats and server channels: Planned — the group encryption code is in the repository, but it is switched off in the shipping app and the messages it would build do not yet carry a signature identifying the sender. Until that is fixed and reviewed, treat anything you write in a group or a channel as unprotected.
  • Old-message protection: Planned — the mechanism that would keep old messages safe if a key is later stolen is written and tested in the repository, but it is deliberately switched off in the live path pending independent review. OSL does not claim it today.

X25519 and ML-KEM-768 are combined in a "hybrid" mode. An attacker would have to break both to recover your keys. If quantum computers turn out to break X25519 some day, ML-KEM-768 still holds. If a flaw is found in ML-KEM-768, X25519 still holds. You get the benefits of both algorithms and the failure mode of neither.

Where your keys live #

The reviewed source generates identity keys locally. The Hub stores the private half through a persistent TPM or operating-system credential-store sealer and refuses identity creation when neither is available; the public half is published to the OSL key server so contacts can encrypt to you. The main password is a separate gate and file-storage-key source. This narrow source-inspected claim is not runtime verification of a named release or protection against malware, memory inspection, backups, swap, crash dumps, or compromise of the operating-system credential boundary.

We never see your keys. We have no copy of them. We can't recover them if you lose them. This is the trade-off for end-to-end encryption: nobody else can read your data, and that includes us.

What connected services see #

The underlying social or email service still handles delivery. From its perspective:

  • They can see: timestamps, recipients, message sizes, online activity, and service groups or accounts.
  • They cannot see: the contents of your messages, your encryption keys, your OSL whitelist, or the relationships between OSL users.

This is the meaningful limit of OSL. We protect content, not metadata. If you need both, look at Signal or Session. They were designed for that threat model from day one. See our threat model for a deeper discussion of what's and isn't covered.

Audit the crypto #

OSL is fully open source. The entire client is on GitHub under Apache-2.0, and the Audit page points you straight at the crypto. Reading the code lets you verify how messages are encrypted. It doesn't guarantee that the code is bug-free, but it means you can check.

The only exception is the optional AutoScrub module planned for the future; it would stay closed source purely to make trivial cloning harder. That module does not exist yet, so everything OSL ships today is open. The exception is deliberately narrow: it does not cover cryptography, trust and identity, deletion receipts, data formats, policy contracts, Free Scrub, or the default client — all of those stay open. If AutoScrub is introduced, it would be separately downloaded only after a plain closed-source warning and explicit consent, and a reproducible fully open-source build would remain usable without it.