SafeMeet / PQC Research
Version 1.0 · released 15 August 2026Post-quantum cryptography at SafeMeet
We are building SafeMeet's end-to-end encryption on hybrid classical and post-quantum cryptography, and publishing the complete design, the protocol specification and the reference implementation so that cryptographers can review it, reproduce it, and tell us where it is wrong.
- Core version
- SafeMeet E2EE Core v1.0
- Released
- 15 August 2026
- Key establishment
- ML-KEM-768 + X25519
- Identity signatures
- ML-DSA-44 + Ed25519
Why post-quantum encryption matters now, not later
Nearly every secure messenger in use today — including SafeMeet as it ships now — establishes keys using elliptic-curve cryptography. A sufficiently capable quantum computer would break that mathematics. The part that changes the timeline is that it would break it retroactively.
An adversary does not need a quantum computer today to benefit from one tomorrow. They only need to record encrypted traffic now, store it, and decrypt it once the hardware exists. This is known as harvest-now, decrypt-later. It means the deadline for post-quantum protection is not the day quantum computers arrive — it is the day your data is first transmitted.
For a conversation that must stay confidential for ten or twenty years — a legal matter, a medical record, a source protecting their identity, a government or defence communication — the protection has to be in place now.
What hybrid cryptography means
SafeMeet does not replace classical cryptography with post-quantum cryptography. It runs both, and binds them together.
Every message key depends on both a classical X25519 contribution and a post-quantum ML-KEM-768 contribution, combined through a domain-separated HKDF-SHA-256 combiner. An attacker has to break both branches to learn anything.
- If ML-KEM turns out to have a weakness, the classical branch still protects the conversation.
- If elliptic curves fall to a quantum computer, the post-quantum branch still protects it.
- Neither branch alone is a single point of failure.
What SafeMeet Core E2EE v1.0 does
Six mechanisms, each described in full in the whitepaper and specified normatively in the protocol specification.
Post-quantum device identity
Each device publishes a bundle carrying classical and post-quantum public keys. The ML-KEM key is signed with Ed25519 and ML-DSA-44, then the complete bundle is signed again at a second layer. Verification runs against the user and device identity the caller expects, not the identity the bundle asserts about itself.
Olm-ML-KEM Session Binding
SafeMeet's hybrid setup binds verified ML-KEM-768 material and both endpoint device bundles to an already established classical Olm session. The transcript ties together the classical session identifier, both bundles and the post-quantum ciphertext, so no piece can be transplanted into another conversation.
EC-PQ Epoch Ratchet
One-to-one messages run a classical X25519 message-ratchet branch alongside a sparse ML-KEM epoch branch that refreshes post-quantum entropy at intervals rather than on every message. The two are combined by a domain-separated HKDF-SHA-256 v2 combiner and sealed with XChaCha20-Poly1305.
Commit-after-AEAD
On receive, classical and post-quantum steps are prepared tentatively, the ciphertext is authenticated, and only then is cryptographic state committed. Invalid ciphertext cannot advance the ratchet, so an attacker cannot desynchronise a session by injecting garbage. Skipped keys, pending queues and future-epoch gaps are all bounded.
Group rooms
Rooms use sender-key encryption. Room keys are sealed per device over one-to-one channels that production policy requires to be post-quantum protected, and room state is ML-DSA signed with membership, room epoch, member epoch and event ordering all bound in.
Fail-closed by construction
The production profile rejects legacy frames, requires post-quantum mode and expected-identity verification, fails closed on identity change, refuses classical-only downgrade when a PQ prekey is missing, and demands PQ-protected room-key channels. Compile-time gates stop a test or migration build from shipping as production.
Cryptographic primitives
| Purpose | Primitive | Standard / note |
|---|---|---|
| Post-quantum key establishment | ML-KEM-768 | NIST FIPS 203. Contributes shared secrets at session setup and at each sparse PQ epoch. |
| Post-quantum signatures | ML-DSA-44 | NIST FIPS 204. Authenticates device identity and bundle material. |
| Classical signatures / identity | Ed25519 | Runs alongside ML-DSA-44 so neither signature scheme stands alone. |
| Classical ratchet material | X25519 | Drives the per-message classical ratchet branch. |
| Payload encryption | XChaCha20-Poly1305 | AEAD with extended nonces; envelope metadata bound as AAD. |
| Key derivation | HKDF-SHA-256 | Used in session binding, backup paths and the v2 final EC-PQ combiner, with deterministic known-answer tests. |
| Secret handling | Zeroizing wrappers |
Intermediate key material explicitly zeroized; #![forbid(unsafe_code)] at crate level.
|
Two documents, two audiences
Both describe the same v1.0 core. The whitepaper explains the design; the specification is precise enough to audit against.
SafeMeet Core E2EE Security Whitepaper
Technical Whitepaper for the Post-Quantum Cryptographic Core. Version 1.0, 15 August 2026 · 22 pages · 18 sections and two appendices.
Describes the algorithms, protocol architecture, implementation structure and the Rust source modules that implement them. Includes the threat model, per-mechanism design rationale, a module map with source paths, and a 74-entry terminology glossary. Start here if you want to understand how the system works.
Protocol Specification & Audit Readiness
Normative, implementation-grounded specification. Version 1.0, 15 August 2026 · 30 pages · 33 sections and three appendices.
Written so a cryptographic reviewer can reconstruct message formats, signed transcripts, KDF inputs, state transitions, replay rules and persistence assumptions without reverse engineering the Rust first. Uses MUST/SHOULD normative language and carries the wire-format registry, domain-separation registry, state-transition tables and the audit gap register.
Reference implementation and reproducibility
Both documents describe one frozen source snapshot. The hashes below are the reproducibility anchor — if you are reviewing the design, verify that the archive you received matches them.
- Implementation snapshot
- safe-e2ee-core-production-v1.0.zip
- Core archive SHA-256
- c88928d64b07cd0789481b4f21ba9a7fe405df20dc8589158853bd75dc383210
- vodozemac archive SHA-256
- 4c19093a137f5b794f56e9e4db4e1ef6b2818f41e5c751940fa23d6575c146d9
The v1.0 release package contains the frozen core archive and the exact sibling vodozemac dependency used for
reproduction. The core archive is distributed without .git metadata.
How SafeMeet compares with Signal
Signal is the most closely studied end-to-end encryption protocol in existence and the first major messenger to ship post-quantum key agreement. For most readers it is the natural reference point, so this table is offered as orientation.
SafeMeet's constructions are its own. SafeMeet Olm-ML-KEM Session Binding is not Signal PQXDH, and no Signal analysis or proof transfers to it. Similar motivation and similar structure do not mean equivalent assurance. Where the two designs resemble each other, that resemblance is a design choice — not inherited evidence.
| Dimension | SafeMeetCore E2EE v1.0 | SignalPQXDH + Triple Ratchet |
|---|---|---|
| Initial post-quantum key establishment | Olm-ML-KEM Session Binding. ML-KEM-768 bound to an existing classical Olm session; transcript covers both device bundles, the session identifier and the PQ ciphertext. | PQXDH. X25519 combined with ML-KEM-1024 at the initial handshake. |
| Continuous post-quantum ratcheting | EC-PQ Epoch Ratchet — X25519 message branch plus a sparse ML-KEM-768 epoch branch, joined by a domain-separated HKDF-SHA-256 v2 combiner. | Triple Ratchet — Double Ratchet plus SPQR, a chunked sparse ML-KEM-768 ratchet. |
| Post-quantum identity authentication | ML-DSA-44 and Ed25519 dual signatures, applied to the signed ML-KEM key and again to the complete device bundle, with algorithm identifiers inside the signed data. | Classical Ed25519 identity keys. The PQXDH specification states that mutual authentication still relies on the hardness of the discrete log problem. |
| Identity substitution resistance | Bundles verified against a caller-supplied expected user and device identity, so a validly signed bundle for the wrong subject is rejected. | Identity keys pinned per contact; safety numbers surface changes to the user. |
| Receive-state discipline | Commit-after-AEAD. Staged receive steps committed only after authentication. Bounded skipped keys (1,024), pending queue (128) and future-epoch gap (8). | Established Double/Triple Ratchet skipped-key and out-of-order handling, hardened over a decade of deployment. |
| Group messaging | Sender-key rooms with room keys sealed per device over channels production policy requires to be PQ-protected, plus ML-DSA-signed verified room state binding membership, epochs and event ordering. | Sender Keys distributed over pairwise sessions, which are themselves post-quantum protected. |
| Group post-compromise recovery | Rotation-based. Not a full post-quantum group key agreement, and not per-message group PCS. | Rotation-based. Sender-key designs do not provide per-message group PCS. |
| Downgrade resistance | Canonical MPQFRAME V2 binds version, cipher suite and frame type; six-axis fail-closed policy; compile-time gates reject legacy and test-support features in production builds. | Protocol-level version and cipher-suite enforcement. |
| Published specification | Whitepaper plus a normative protocol specification with wire-format and domain-separation registries, state-transition tables, and a public audit gap register. | Published protocol specifications and peer-reviewed research papers. |
Signal details reflect published Signal specifications and research as of August 2026.
Post-quantum identity, not only post-quantum secrecy
Signal's PQXDH protects the confidentiality of the key agreement against a future quantum attacker, but identity keys remain elliptic-curve and the specification is explicit that mutual authentication still rests on the discrete log problem. SafeMeet signs the ML-KEM public key and the entire device bundle with ML-DSA-44 alongside Ed25519, so a quantum-capable adversary cannot forge a SafeMeet device bundle. That matters for active attacks, not only for recorded traffic.
Sparse ratcheting, reached independently
Running a post-quantum KEM on every message is expensive in both computation and bandwidth. Signal's SPQR and SafeMeet's EC-PQ Epoch Ratchet solve that the same way: inject ML-KEM entropy at epoch boundaries, derive per-message keys from the resulting chain, and mix classical and post-quantum keys so both must be broken. Both settled on ML-KEM-768 for the ratchet. Convergent design by independent teams is reassuring about the approach — it is not shared evidence.
What is implemented, and what is not
Taken from section 17 of the whitepaper and the audit gap register in section 28 of the specification.
| Core area | Status | Technical note |
|---|---|---|
| Primitives and hybrid derivation | Implemented | ML-KEM-768, ML-DSA-44, Ed25519, X25519, XChaCha20-Poly1305 and domain-separated HKDF-SHA-256 composed in the SafeMeet protocol profile. |
| Olm-ML-KEM Session Binding | Implemented | SafeMeet-specific transcript and AAD binding extends an existing Olm context; the production opening path is replay-aware. |
| EC-PQ Epoch Ratchet | Implemented | Per-message EC evolution and sparse PQ epochs with commit-after-AEAD receive semantics and bounded pending/skipped state. |
| Replay protection | Implemented | Dedicated replay domains covering initial binding, one-to-one messages, pending duplicates, room messages and room-state events. |
| Framing and parser hardening | Implemented | Canonical MPQFRAME parsing checks version, cipher suite, frame type, reserved fields, lengths and trailing bytes. |
| Identity and bundles | Implemented | Nested Ed25519 + ML-DSA signatures with expected-identity verification binding device and algorithm context. |
| Trust and verification | External hooks | TOFU and safety numbers implemented; cross-signing and Key Transparency are integrated as evidence interfaces, not services. |
| Group cryptography | Defined scope | Sender-key room encryption and verified room-state policy implemented. This version is not a full post-quantum group key-agreement protocol. |
| Backup envelope | Implemented | Typed E2EE records exported under HKDF/XChaCha20-Poly1305. Recovery service and UX are outside the core. |
| Fail-closed policy | Implemented | Strict policy axes and compile-time feature guards limit legacy, missing-PQ, identity-change and non-PQ room-key paths. |
| Fuzzing and adversarial testing | Baseline | Parser/envelope fuzzing, an initial stateful EC-PQ fuzz target, randomized long-trace tests and persistence fault-injection tests are present. Sustained campaign evidence remains to be produced. |
We are looking for peer review and an independent audit
The specification was written to be audited against. If you work on secure messaging, protocol analysis, formal methods or cryptographic implementation, we want your scrutiny.
Four questions a cryptographic engagement should answer
Section 31 of the specification scopes a specialist engagement around four questions rather than a generic code review:
1. Hybrid composition
Does the final construction achieve the intended property that breaking only the EC branch or only the ML-KEM branch does not reveal the message key, considering exact context binding and state transitions?
2. Forward secrecy and PCS across the epoch cycle
Do the stated forward-secrecy and post-compromise-security properties hold before, during and after epoch changes, under both passive and active adversarial scheduling, including in-flight retained decapsulation keys?
3. Long-trace state-machine soundness
Can an adversary reach an invalid state through reordering, duplicates, pending queues, authentication failures, retries, crashes or concurrent commits? Are at-most-once commit, monotonicity and bounded-state properties preserved?
4. Classical trust boundary and downgrade
Does the vodozemac/Olm boundary preserve the assumptions the post-quantum extension makes, including session identifier binding, rejection of unsupported legacy paths, and X25519 edge cases?
A separate implementation workstream should review constant-time behaviour, secret zeroization, allocator lifetime and platform storage semantics.
Open items we already know about
The specification carries a full audit gap register. These are the priority-zero entries — the ones we consider most important to close before the design can carry stronger claims.
| ID | Area | Status | Required closure |
|---|---|---|---|
| AR-01 P0 | PQ epoch transport under selective drop | Open | Define epoch trigger, retransmission and progress behaviour under outstanding epochs and adversarial drop; model it. |
| AR-02 P0 | Final hybrid combiner | Implemented | HKDF-SHA-256 v2 and known-answer tests exist. Independent composition review or formal argument still required. |
| AR-03 P0 | Formal ratchet model | Partial | Execute and refine the Tamarin models, preserve proof logs and counterexamples, and obtain independent review of model-to-code correspondence. |
| AR-04 P0 | ML-KEM decapsulation-key lifecycle | Open | Specify retention bound, expiry, consumption, retirement, replenishment, crash recovery and zeroization. |
| AR-05 P0 | vodozemac / classical boundary | Evidence required | Pin exact source; verify all-zero behaviour, reachable protocol versions, session-ID semantics and local patches. |
| AR-07 P0 | Atomic receive persistence | Partial | Integrate ratchet and replay bytes into one durable transaction or prove a host equivalent; fault-inject. |
| AR-16 P0 | Outbound ratchet crash atomicity | Open | Staged send state, durable commit and idempotent publish/retry, with fault-injection tests. |
The complete register, including P1 and P2 items, is in section 28 of the protocol specification.
Reviewing independently
Read the specification, verify the archive hashes, and send findings through the feedback form. Tell us which section you are commenting on — the form has a section selector for both documents.
Engaging as an auditor
If you are a firm or academic group interested in a formal engagement, get in touch through the feedback form and select “audit or collaboration”. We can supply the evidence package described in section 32 of the specification.
Post-quantum encryption, briefly
What is post-quantum encryption?
Post-quantum cryptography refers to algorithms designed to remain secure against attacks from sufficiently capable quantum computers. Most encryption in use today establishes keys using elliptic-curve mathematics, which a large quantum computer would be able to break. Post-quantum algorithms such as ML-KEM and ML-DSA rest on different mathematical problems that are not known to be vulnerable to the same attacks.
What is harvest-now, decrypt-later?
It describes an adversary recording encrypted traffic today and storing it until a quantum computer capable of breaking that encryption exists. Because the recorded traffic can be decrypted retroactively, any conversation that must remain confidential for many years needs post-quantum protection now rather than when quantum computers arrive.
What is hybrid post-quantum encryption?
Hybrid cryptography combines classical and post-quantum inputs so security does not rely on a single cryptographic family. In SafeMeet's design each message key depends on both a classical X25519 contribution and a post-quantum ML-KEM-768 contribution, combined through a domain-separated HKDF-SHA-256 combiner, so an attacker must break both branches.
Which post-quantum algorithms does SafeMeet use?
SafeMeet Core E2EE v1.0 uses ML-KEM-768 (NIST FIPS 203) for post-quantum key establishment and ML-DSA-44 (NIST FIPS 204) for post-quantum device identity signatures, alongside classical X25519 and Ed25519, with XChaCha20-Poly1305 for payload encryption and HKDF-SHA-256 for key derivation.
Has SafeMeet's post-quantum core been independently audited?
No. SafeMeet Core E2EE v1.0 is an implementation-grounded reference release. It has not been formally verified or independently audited, and we do not describe it as formally verified, cryptographically proven, or unqualifiedly quantum safe. The published protocol specification includes an audit gap register listing exactly what evidence and independent analysis is still required.
Can I use the source code?
The SafeMeet client source is published for transparency and review. The v1.0 core release package is identified by the archive hashes listed above so you can verify you are reviewing the same snapshot the documents describe.
Tell us where we are wrong
Cryptography does not become safer by being announced. It becomes safer by being reviewed. If you have read either document and found a problem, an overstatement, or something we have failed to specify, we want to hear it.
Reporting a vulnerability? Please do not use the feedback form. Contact contact@safemeet.us privately and do not attempt to exploit the issue.