SafeMeet Core E2EE Security Whitepaper

Executive summary

SafeMeet implements a substantial post-quantum end-to-end encryption core built around hybrid classical and post-quantum cryptography.

Device identity is authenticated using Ed25519 and ML-DSA-44. ML-KEM-768 contributes post-quantum shared secrets during initial session setup and during later sparse post-quantum ratchet epochs. One-to-one messages use a SafeMeet EC-PQ Epoch Ratchet that combines a classical X25519 message-ratchet branch with a sparse ML-KEM epoch branch, and encrypts payloads with XChaCha20-Poly1305.

A central implementation property is the receive-side commit discipline. EC and PQ receive steps are prepared tentatively, the ciphertext is authenticated, and only then is the cryptographic state committed. Together with bounded skipped keys, bounded pending queues, duplicate-pending rejection, and a maximum future-epoch gap, this reduces the risk of state poisoning and resource-amplification attacks.

The identity layer uses two nested authentication boundaries. SignedPQPublicKey binds an ML-KEM public key to device and algorithm context with both classical and post-quantum signatures. DevicePublicBundle then signs the complete device bundle again. Verification requires caller-supplied expected user and device identities, reducing the risk of accepting a valid bundle for the wrong subject.

Canonical MPQFRAME framing binds protocol version, cipher suite, and frame type, rejects non-zero reserved fields, validates lengths, and rejects trailing bytes. Production feature gates disable legacy parsing paths and reject incompatible feature combinations at compile time. Therefore, legacy compatibility is principally a non-production and migration concern rather than an exposed production parser path in the inspected build configuration.

Group messaging uses a sender-key room session. Room keys are distributed through PQ-protected one-to-one E2EE channels, and verified room-state logic binds active membership, room epoch, member epoch, event ordering, and trusted signers. This is not a full post-quantum group key agreement protocol, and group post-compromise recovery remains dependent on room-key rotation rather than per-message group ratcheting.

This whitepaper presents the first technical description of the SafeMeet E2EE core and its reference implementation. The focus is the design and composition of the cryptographic algorithms, the protocol state transitions, canonical encodings, replay and ordering behavior, trust controls, group sender-key construction, backup-envelope cryptography, and the Rust source modules that implement them. The document also states the current technical limitations and directions for future development.

1. Scope and document overview

This section defines the scope of the first SafeMeet E2EE core version and the relationship between the protocol description and the accompanying source implementation.

The whitepaper describes the cryptographic behavior implemented by the SafeMeet E2EE core, including public-key identity, signed device bundles, hybrid session setup, ratchet state transitions, message envelopes, AEAD context binding, replay logic, trust decisions, group sender-key cryptography, backup-envelope cryptography, fail-closed policy, and implementation testing.

The document intentionally does not design general messaging infrastructure. References to an “adversarial delivery path” are threat-model assumptions used to explain parser, replay, ordering, and state-transition behavior; transport, server, account, and user-interface systems remain outside the E2EE core described here.

1.1 In-scope components

1.2 Document status

This paper is implementation-grounded. Algorithms and data flows are described together with the Rust modules that implement them. Where functionality depends on a host application or remains incomplete in the initial project version, that limitation is stated explicitly. The whitepaper is a technical description of the design and source implementation, not a formal proof of the protocol.

2. Security objectives and terminology

2.1 Core security objectives

• Confidentiality: message plaintext and secret key material should be recoverable only by intended endpoints.
• Integrity and context binding: modification of ciphertext or authenticated metadata must cause decryption failure.
• Hybrid security: the message key should depend on both classical and post-quantum inputs so that compromise of only one branch is insufficient under the intended composition.
• Post-quantum protection: ML-KEM-768 should contribute secrecy at session establishment and later sparse PQ epochs; ML-DSA-44 should contribute long-term authenticity of device key material.
• Identity substitution resistance: public keys must be bound to caller-expected user, device, and algorithm context.
• Replay and reordering resistance: duplicate, delayed, reordered, and future-epoch messages must be handled without silent acceptance or unbounded state growth.
• State-poisoning resistance: invalid ciphertext must not advance long-lived ratchet state.
• Downgrade resistance: production code must fail closed on non-canonical frames, unsupported cipher suites, identity changes, and missing PQ material.

2.2 Terminology

A comprehensive glossary of the terminology and concepts used throughout this whitepaper is provided in Appendix B.

3. Core architecture

The core is divided into narrow layers so that identity, key agreement, ratcheting, parsing, replay, and trust can fail independently and explicitly.

1. Verified device bundle
2. Hybrid Olm + ML-KEM session binding
3. SafeMeet EC-PQ Epoch Ratchet
4. XChaCha20-Poly1305 + context-bound AAD
5. Canonical MPQFRAME parser + replay/order checks
6. Commit cryptographic receive state only after authentication

3.1 Architectural principles

• Authenticate before using key material. Device bundles and nested PQ keys are verified against externally expected identities before cryptographic use.
• Bind context into every security boundary. User, device, session, epoch, message, room, algorithm, and frame metadata are included in signed payloads, key derivation, replay identifiers, or AEAD AAD.
• Separate parse from policy. Canonical parsers validate binary structure; production policy separately rejects legacy input and unsupported suites.
• Stage before commit. Receive branches calculate tentative next state, authenticate the ciphertext, and commit only after success.
• Bound attacker-controlled state. Skipped keys, pending messages, and future epoch gaps are limited.
• Fail closed on trust regressions. Identity changes, stale or mismatched evidence, and unsupported room-key flows are rejected.

3.2 Core layer map

4. Cryptographic threat model

The core assumes that all wire-facing inputs and downloaded public key material may be adversarial. An attacker may replay, reorder, duplicate, truncate, mutate, substitute, or cross-context transplant envelopes and public bundles. The parser and cryptographic state machine must reject such inputs without revealing plaintext or advancing state incorrectly.

4.1 Adversary capabilities

• Supply malformed, truncated, oversized, non-canonical, or trailing-byte protocol inputs.
• Replay an initial Olm-ML-KEM binding envelope or a previously accepted one-to-one or room message.
• Reorder valid messages, delay an epoch update, or send a bounded-future message before its required PQ epoch is available.
• Replace individual keys inside a bundle, replace the complete bundle, or change algorithm identifiers.
• Present a valid bundle for the wrong user or device identity.
• Tamper with PQ ciphertext, EC public keys, message numbers, epochs, indexes, or AAD-bound room metadata.
• Attempt downgrade through legacy payloads, alternate cipher suites, missing PQ material, or non-PQ room-key distribution.
• Attempt to exhaust skipped-key or pending-message state through large gaps or duplicate inputs.

4.2 Out-of-scope compromise

A fully compromised endpoint can read plaintext and live key material and is outside the protection boundary of the cryptographic protocol. The core also does not claim metadata hiding, traffic-analysis resistance, or protection against a malicious authorized recipient. These exclusions do not reduce the requirement that the core reject hostile protocol inputs and preserve state-machine integrity.

5. Primitives, key derivation, and domain separation

5.1 Primitive suite

5.2 Domain separation

Distinct domain strings separate device-bundle signatures, signed PQ keys, Olm-ML-KEM binding derivation, initial payload encryption, one-to-one message derivation, room message derivation, replay identifiers, safety numbers, and backup envelopes. Length-prefixing is used in several composite encodings to reduce ambiguity between variable-length fields.

5.3 Hybrid composition qualification

The SafeMeet Olm-ML-KEM Session Binding and backup paths use HKDF-SHA-256. The SafeMeet EC-PQ Epoch Ratchet uses an explicit domain-separated HKDF-SHA-256 v2 final combiner: the EC and PQ message-key contributions are length-prefixed into IKM, public ratchet context is bound into both the extract salt and expand info, and XChaCha20-Poly1305 authenticates the corresponding envelope metadata. This construction is part of the initial SafeMeet protocol profile and is covered by deterministic known-answer tests in the source repository.

6. Device identity and public bundles

SafeMeet binds device identity to both classical and post-quantum public material. The design uses nested authentication rather than relying on a single signature over an informal serialization.

6.1 SignedPQPublicKey

• Contains the ML-KEM public key and algorithm context.
• Binds the key to the intended device context.
• Carries both Ed25519 and ML-DSA signatures.
• Includes algorithm identifiers in the signed data, preventing silent algorithm substitution.

6.2 DevicePublicBundle

• Contains classical identity and prekey material, Ed25519 identity, ML-DSA identity, signed ML-KEM material, and related public context.
• Signs the complete bundle at a second layer with Ed25519 and ML-DSA.
• Checks consistency between nested and outer identity material.
• Verifies against an ExpectedDeviceIdentity supplied by the caller rather than trusting only the bundle's embedded user_id and device_id.

6.3 Security properties

The remaining structural limitation is first-contact authenticity. A completely substituted but internally valid bundle can still be accepted on first use unless the user or application supplies stronger evidence such as a verified safety number, cross-signing result, or key-transparency result.

7. SafeMeet Olm-ML-KEM Session Binding

SafeMeet Olm-ML-KEM Session Binding is a SafeMeet-specific construction that binds verified ML-KEM-768 material and both endpoint device bundles to an already-established classical Olm session context.

7.1 Initiator flow

1. Verify both endpoint device bundles against expected identities.
2. Extract the responder's verified ML-KEM-768 public key.
3. Encapsulate to obtain a PQ shared secret and PQ ciphertext.
4. Construct transcript material containing the classical Olm session identifier, both device bundles, and the PQ ciphertext.
5. Derive a hybrid session identifier and initial payload key.
6. Encrypt the initial payload with XChaCha20-Poly1305 and context-bound AAD.
7. Serialize the result as HybridEnvelope structural version 1 inside canonical MPQFRAME V2.

7.2 Receiver flow

1. Parse and validate canonical MPQFRAME V2, the approved cipher suite, HybridEnvelope frame type, and the structural-version-1 payload.
2. Verify expected sender and recipient bundle identities.
3. Decapsulate the ML-KEM ciphertext with the responder private key.
4. Reconstruct the transcript and derive the same session identifier and initial payload key.
5. Authenticate and decrypt the initial payload.
6. Record the dedicated initial-handshake replay identifier only after successful authentication.

7.3 Binding and security properties

• The PQ ciphertext is not free-standing; it is included in transcript derivation.
• Both endpoint bundles are included, reducing cross-device and cross-conversation transplantation risk.
• The classical Olm session identifier binds the PQ extension to the established classical context.
• AAD binds the initial payload to its cryptographic context.
• Unsupported PQ algorithms, incorrect classical session identifiers, wrong private keys, substituted bundles, and tampered ciphertext are covered by negative tests.

7.4 Qualification

The module does not implement the complete classical authenticated handshake by itself. It binds ML-KEM material to an existing Olm session context supplied by vodozemac, so the trust boundary includes that classical implementation and the correctness of the session identifier passed into the binding construction.

The current profile uses SafeMeet-specific safemeet-core-olm-mlkem-* v2 KDF/AAD domains, a safemeet-olm-mlkem768-v2: session identifier prefix, and MPQFRAME V2 for HybridEnvelope while retaining structural payload version 1.

The core provides dedicated initial Olm-ML-KEM binding replay APIs, and the production wrapper requires replay state and a successful replay commit before plaintext is returned. Lower-level primitives remain available for tests or advanced integrations, so production callers must use the replay-aware high-level path or provide an equivalent at-most-once commit discipline.

8. One-to-one SafeMeet EC-PQ Epoch Ratchet

After setup, SafeMeet uses EcPqEpochRatchetState, the implementation of the SafeMeet EC-PQ Epoch Ratchet. The construction combines a per-message classical EC ratchet branch, a sparse ML-KEM epoch branch, a domain-separated HKDF-SHA-256 final combiner, and XChaCha20-Poly1305 authenticated encryption.

8.1 EC message branch

ECMessageRatchetState derives per-message classical material using X25519-based ratchet state. On receive, the next state is represented as a tentative receive step. The branch does not irreversibly advance when the envelope is merely parsed or when key derivation begins.

8.2 Sparse PQ epoch branch

GeneralSparsePQState injects ML-KEM entropy at epoch boundaries rather than performing a KEM operation for every message. Each epoch establishes a PQ chain key, from which per-message PQ keys are derived. This amortizes the cost and size of post-quantum operations while periodically refreshing the PQ contribution.

8.3 Per-message hybrid key

For every message, the final AEAD key depends on the EC message key, the PQ message key, the classical session identifier, message number, PQ epoch identifier, epoch message index, sender next EC public key, and any PQ epoch update. AAD independently authenticates the corresponding envelope metadata.

8.4 Bounded state

• Duplicate pending envelopes are rejected.
• Message and epoch metadata are cross-checked between EC, PQ, and envelope state.
• Temporary final, EC, and PQ message keys are zeroized after use.

8.5 Staged decrypt and commit-after-AEAD

1. Parse canonical envelope
2. Check policy, replay, gaps, and duplicates
3. Prepare EC receive step
4. Prepare or resolve PQ receive step
5. Derive final message key and AAD
6. Authenticate / decrypt XChaCha20-Poly1305
7. On failure: discard tentative state
8. On success: commit EC state, PQ state, counters, and replay metadata

This is an important implementation property. Invalid ciphertext cannot directly advance the EC branch, install a PQ epoch update, or consume the staged message state. The term “transactional” should nevertheless be understood as a cryptographic state-machine property: the core prepares and commits in-memory state in a controlled order. It is not, by itself, a claim about an external persistence transaction.

9. Replay, ordering, and state-poisoning resistance

9.1 Replay domains

The core's responsibility is to reject repeated cryptographic objects and cross-context reuse. Application-level retry semantics are not part of the cryptographic claim; callers should not interpret replay rejection as a complete idempotent delivery protocol.

9.2 Out-of-order delivery

Within configured bounds, skipped EC and PQ keys allow a delayed message to be decrypted after later messages have arrived. If the required PQ epoch is not yet available, the envelope may be buffered. Pending entries and skipped-key storage are bounded to prevent attacker-controlled memory growth.

9.3 State-poisoning resistance

State poisoning occurs when malformed input causes a receiver to advance before authenticity is known. SafeMeet mitigates this by separating parsing, tentative key/state derivation, AEAD authentication, and final commit. The same principle is applied to optional PQ updates: a malicious update cannot be installed solely because it appears in a parseable envelope.

10. Canonical framing and downgrade resistance

10.1 MPQFRAME

10.2 Protocol encoding

protocol_encoding.rs provides explicit little-endian integer encoding, length-prefixed bytes and strings, fixed-length reads, UTF-8 validation where relevant, overflow checks, truncation rejection, and ensure_finished() checks. Envelope-specific parsers additionally verify the expected MPQFRAME type and cipher suite.

10.3 Legacy compatibility

The source still contains from_canonical_or_legacy_bytes() helpers for tests and non-production builds. In the inspected production configuration, those functions are guarded by cfg(any(test, not(feature = "production"))) and legacy-migration cannot be combined with production because lib.rs emits compile_error!. Therefore, the production feature profile does not expose transparent legacy fallback on the strict canonical path.

A small API-hardening improvement would be to gate all legacy helpers exclusively behind a named legacy-migration feature, rather than compiling them for every non-production build. This would reduce accidental use during integration without changing the current production posture.

11. Trust, TOFU, and verification evidence

11.1 TOFU pinning

The trust store pins the Ed25519 identity key and a domain-separated hash of the ML-DSA public identity key for each expected user/device pair. Later observations must match the pinned material. A valid but replaced bundle therefore fails after the first accepted observation.

11.2 Safety numbers

Safety numbers are derived from ordered local and peer identity material under a dedicated domain. They provide a human-verifiable channel for increasing identity confidence beyond TOFU, for example by comparison in person, by voice, or through a QR workflow implemented by the host application.

11.3 Evidence model

identity_verification.rs evaluates evidence and rejects subject mismatch, fingerprint substitution, stale or incomplete transparency results, and downgrade from stronger existing trust states. Cross-signing and key-transparency verification engines themselves are interfaces, not implementations inside the core.

12. Group sender-key cryptography

12.1 Room message encryption

Each sender creates an outbound room session with a random symmetric chain key. For each room message, the session derives a message key and the next chain key, then encrypts with XChaCha20-Poly1305. AAD binds room ID, session ID, sender user ID, sender device ID, and message index.

The inbound room session checks the expected room, session, sender, device, and message-index behavior. It tracks seen indexes and supports bounded out-of-order decryption through skipped room-message keys. State advances only after successful AEAD authentication.

12.2 Room-key distribution

RoomKeyPayload is encoded canonically and sealed separately for each eligible device through a one-to-one E2EE channel. Production policy requires that channel to be marked PQ-protected. The receiver validates intended recipient, room, session, sender, and framing before constructing an inbound room session.

12.3 Verified room state and epoch policy

• Trusted room signers are populated only from already verified device bundles and trust decisions.
• Room-state events are ML-DSA signed and form a linear chain through prev_event_id.
• Duplicate event IDs, wrong previous events, invalid signer roles, membership skips, and epoch inconsistencies are rejected.
• Room-key sharing context binds active sender and recipient membership, room epoch, member epoch, and a room-state hash.
• Unsupported room-key requests and forwarded-room-key flows fail closed rather than silently exposing keys.

12.4 Security qualification

The correct claim is: SafeMeet provides sender-key group encryption whose room keys can be distributed over PQ-protected one-to-one E2EE channels, with verified room-state and epoch policy. It is not a full post-quantum group key agreement protocol. The symmetric sender-key chain also provides weaker post-compromise recovery than the one-to-one EC-PQ epoch ratchet; recovery depends on generating and redistributing a fresh room session after a rotation trigger.

13. Backup-envelope cryptography

backup_envelope.rs defines a client-side cryptographic envelope for exporting and restoring typed E2EE records. This section evaluates only the envelope and validation contract, not any backup lifecycle or recovery service.

13.1 Envelope construction

• Requires a high-entropy recovery key of at least 32 bytes.
• Generates a 32-byte random salt and 24-byte XChaCha nonce.
• Derives an encryption key with HKDF-SHA-256 under a backup-specific domain.
• Encrypts serialized typed records with XChaCha20-Poly1305.
• Authenticates owner user ID, owner device ID, backup ID, backup version, creation time, schema version, salt, and nonce as AAD.

13.2 Parser and context validation

The MPQBACKUP envelope contains explicit magic, envelope version, schema version, length-prefixed context strings, version counters, salt, nonce, and length-prefixed ciphertext. The parser rejects bad magic, unsupported versions, malformed lengths, truncation, invalid context, and trailing bytes. The sealing path also rejects records that do not belong to the owner/device context being authenticated.

13.3 Security properties and limitations

Negative tests cover wrong recovery keys, wrong user/device context, backup version drift, header tampering, salt and nonce tampering, ciphertext and tag tampering, malformed lengths, truncation, and trailing bytes. This is a meaningful cryptographic primitive, but it should be described as an encrypted backup/export envelope rather than a complete recovery system.

14. Fail-closed policy and production core API

14.1 Production policy

E2eePolicy::production() activates all six controls. Strict parsing wrappers call policy checks before decoding and verify the expected approved cipher suite. The default policy is the production profile.

14.2 Compile-time feature gates

The crate forbids unsafe code and rejects production builds that enable test-support, legacy-migration, kyber-legacy, post-quantum-all, or the non-approved ML-KEM backend. Production also requires the mlkem-pqcrypto backend. These compile-time checks reduce the chance that a permissive migration or test configuration is accidentally shipped as the production core.

14.3 API discipline

ProductionE2eeContext centralizes strict policy and preferred entry points. For the initial Olm-ML-KEM Session Binding path, the high-level open API structurally requires replay state and commits the replay record before returning plaintext. Remaining API-hardening work is concentrated in persistence atomicity, stateful ratchet testing, and deployment integrations rather than omission of initial-handshake replay checking.

15. Implementation and testing

15.1 Implementation properties

• #![forbid(unsafe_code)] at crate level.
• Explicit zeroization or Zeroizing wrappers for secret and intermediate key material.
• Redacted Debug implementations for recovery keys, ciphertext containers, and security-sensitive values.
• Security-event redaction tests to prevent secret leakage into logs.
• Strict canonical encoders and decoders with negative boundary tests.

15.2 Adversarial and state tests

The test suite includes handshake downgrade tests, identity substitution vectors, parser mutation vectors, cross-context replay, one-to-one and group adversarial flows, room epoch policy, multi-device rotation, backup tampering, concurrency races, security-event redaction, and strict production feature gates. The breadth of negative testing is a major strength because most messaging failures occur in composition and state transitions rather than in the nominal encryption call.

15.3 Fuzz targets

HybridEnvelope and EcPqEpochEnvelope are exercised by protocol-frame fuzzing. The repository also includes an initial stateful EC-PQ ratchet fuzz target and randomized / fault-injection integration tests. These artifacts establish a basis for long-trace testing; sustained fuzz campaigns, coverage measurements, corpus management, and preserved run evidence remain future work.

15.4 Additional testing directions

• The initial repository focuses on the implementation and automated test suite; additional independent analyses may be developed as the project evolves.
• The repository includes initial Tamarin models for the Olm-ML-KEM Session Binding, the EC-PQ Epoch Ratchet, and their combined one-to-one flow, together with a model-to-Rust correspondence map. These models are analysis artifacts rather than completed proofs: machine-checked proof logs, model-completeness review, and independent protocol analysis are not claimed in this version.
• Dedicated constant-time and side-channel measurements of the integration layer are future implementation-analysis tasks.
• The repository contains parser-oriented fuzz targets; longer continuous fuzzing campaigns and corpus management can extend coverage over time.
• Known-answer vectors can be expanded further to cover additional hybrid derivations and complete state-transition traces.

16. Limitations and future work

17. Technical summary

The following table summarizes which major E2EE components are implemented in the initial project version and notes the main technical qualifications of each component.

18. Conclusion

The first SafeMeet E2EE core version combines post-quantum key establishment and authentication with classical cryptography, applies explicit context binding, and treats hostile asynchronous delivery as a state-machine problem. The nested device-bundle signatures, SafeMeet Olm-ML-KEM Session Binding, canonical MPQFRAME parser, bounded SafeMeet EC-PQ Epoch Ratchet, replay domains, verified room state, and fail-closed policy form a coherent cryptographic architecture. The SafeMeet-specific names identify the project's own constructions and do not imply protocol identity with similarly motivated systems.

A central design property is commit-after-AEAD. By staging EC and PQ receive steps and refusing to commit them before ciphertext authenticity succeeds, the design reduces the risk of attacker-induced state desynchronization. Negative tests, parser fuzzing, concurrency tests, and explicit feature gates provide additional implementation coverage.

Future technical work includes sustained stateful-fuzz campaigns, broader deterministic vectors, deeper analysis of hybrid composition and post-compromise behavior, stronger persistence integration, explicit sparse-PQ epoch progress rules under selective message loss, and refinement of ML-KEM epoch-key retention, expiry, replenishment, and deletion rules. Group messaging in this version remains a sender-key construction with PQ-protected pairwise room-key distribution and rotation-based recovery rather than a full post-quantum group key-agreement protocol.

This whitepaper and the accompanying Rust source code define the initial SafeMeet E2EE project version. They provide a concrete reference for the project's algorithms, message formats, state transitions, implementation boundaries, and current technical limitations, and establish the baseline from which later protocol and implementation versions can evolve.

A. Appendix A. Core module map and source paths

B. Appendix B. Terminology and concepts

This appendix provides a consolidated glossary of the principal cryptographic, protocol, state-management, trust, group-messaging, backup, and implementation terms used in this whitepaper. Definitions are specific to the SafeMeet Core E2EE v1.0 context and should be read together with the detailed descriptions in the main body.

End of SafeMeet Core E2EE Security Whitepaper v1.0.