Skip to content
OpenE2EE
Sign inStart free

Security model

What your relay can see

The relay never needs message plaintext or device private keys. It does need routing metadata.

6.0.x

The delivery envelope, field by field

Plaintext and long-term private keys exist only inside a device. This is what a relay adapter receives. Sealed sender omits two of these fields.

One message traveling from one device to another through a relay Two outlined devices with readable contents and a private key inside each. Between them, sealed envelopes drawn as solid slabs leaning in the direction of travel, carrying metadata ticks on their outside edge, and the OpenE2EE mark standing in for the relay. Dotted brass rules mark where the message is sealed and where it is opened.Device A · readableDevice B · readablesealopenmetadata visiblesealedsealedrelay · never needs plaintext One message traveling from one device to another through a relay Two outlined devices with readable contents and a private key inside each, one above the other. Between them, sealed envelopes drawn as solid slabs leaning in the direction of travel, carrying metadata ticks on their outside edge, and the OpenE2EE mark standing in for the relay. Dotted brass rules mark where the message is sealed and where it is opened.Device A · readablesealsealedmetadata visiblerelay · never needs plaintextsealedopenDevice B · readable
FieldIdentified deliverySealed senderWhat it is
targetUserIdvisiblevisibleWho the message is for
targetDeviceIdvisiblevisibleWhich of their devices
senderUserIdvisibleomittedWho sent it
senderDeviceIdvisibleomittedWhich device sent it
messageTypevisiblevisibleHandshake or steady-state
timestampvisiblevisibleWhen it was sent
groupIdvisiblevisiblePresent on group messages
clientMessageIdvisiblevisibleRetry idempotency key
ciphertextopaqueopaqueBytes the relay never needs to read

Some fields appear only in context: recipientRegistrationId accompanies the initial handshake envelope. contentHint is optional. deliveryClass selects durable delivery or an online-only hint. Your relay also assigns its own message identifier and server timestamp.

What sealed sender does not hide

Sealed sender omits the sender fields. It does not make a sender anonymous.

  • Anonymity does not compose over a conversation

    One-sided anonymity breaks when two parties exchange several messages. NDSS 2021 research linked sealed-sender users after as few as five messages, using delivery receipts. Later work extended the technique to whole group conversations. Whether your application supplies that signal is your design decision.

  • When, and roughly how much

    Timestamps are plaintext. Message bodies are padded into 160-byte buckets, which coarsens length without concealing it. Attachments travel through a separate object store.

  • Network-level metadata

    Addresses, connection timing, and traffic patterns belong to your transport and deployment. This SDK implements no decoy traffic and no timing jitter.

  • Sealed sender is best effort

    If the recipient profile key or identity key is unavailable, the client falls back to identified delivery rather than failing the send.

Threat model boundary

An attacker in full control of your relay can serve stale or hostile responses and observe every routing field above. Once trust is pinned, an identity substitution that would reach plaintext fails closed.

First contact is trust on first use. A relay that is hostile from the first message can substitute an identity before trust is pinned. A safety-number comparison closes that gap. After trust is pinned, substituting either half of the identity tuple fails closed until a rotation is explicitly accepted.

Threat model (opens in a new tab)

What there is to check

Each figure carries the date it was measured.

7,073
test cases across 400 modules, 0 failing and 2 skipped, on 2026-09-12. An export is only cut from a revision where they pass.
6
direct production dependencies: @noble/ciphers, @noble/curves, @noble/hashes, @noble/post-quantum, async-lock, unique-names-generator. They resolve to 6 packages in total. The only edges inside the tree run between the @noble packages. Everything else is a development or optional peer dependency.
7
published specifications the implementation profile is pinned to, by revision, in the SDK README (opens in a new tab).
72 hours
to acknowledge a vulnerability report sent to security@open-e2ee.dev, and 7 days to an initial assessment. Resolution targets by severity: critical 24 to 72 hours, high 1 to 2 weeks, medium 2 to 4 weeks, low the next release cycle. Good-faith research on the SDK is covered by the safe harbor in the policy. Do not open a public issue. The full policy is in the repository (opens in a new tab).

Assurance (opens in a new tab)

Published limits

Not audited by any independent firm
Reviewed continuously by adversarial AI agents; not audited by any independent firm. Each substantive code change passes an adversarial AI review before it merges, and recurring whole-codebase AI audit passes run against the engineering repository. The assurance summary (opens in a new tab) states what that covers and what it does not. No independent firm has audited the SDK, and none is engaged.
Standardized algorithms, no module validation
PQXDH uses ML-KEM-1024 as standardized in FIPS 203. Braid mode changes the encapsulation-key commitment, so no FIPS 203 conformance claim holds there. Validation is a separate question: pure-JavaScript cryptography is not FIPS 140-validated. If your program requires a validated module, this SDK does not meet it.
JavaScript is not a constant-time environment
Browser, Node, and React Native engines provide no machine-level constant-time guarantee. Selected paths use best-effort patterns. The SDK claims no timing equivalence against a co-resident adversary.
Memory cannot be reliably wiped
Typed-array overwrites shorten the life of some buffers. Strings, engine temporaries, registers, and garbage-collected pages remain outside the SDK’s control.
Post-quantum means confidentiality, not signatures
Post-quantum key agreement is the default and fails closed, using ML-KEM-1024 for PQXDH and an ML-KEM Braid ratchet. One explicit opt-in, protocol.postQuantum: 'compatible', permits a classical session only when a peer advertises no post-quantum material. Identity signatures remain classical Ed25519 and X25519. The protection is against harvest-now-decrypt-later, not against a quantum adversary forging identities.
There is no key escrow, so device loss is real
Nothing recoverable is held on a server. Transferring state to new hardware requires the old device. A lost device means re-registering, and contacts see a safety-number change.
Not Signal Messenger, and not wire-compatible with it
Messages, identities, and sessions do not cross between this SDK and Signal Messenger. Safety numbers shown here never match the ones a Signal Messenger client displays. DEVIATIONS (opens in a new tab) lists every difference and what it costs.

Read the primary sources

These are the maintained documents. Where one disagrees with this page, the document is right.

Take this to whoever signs it off

Enterprise and OEM agreements include a scoped security review, service levels, and negotiated portfolio or redistribution rights.

Plan a security reviewBuild your first encrypted message

Licensing

Email security@open-e2ee.dev with a threat-model question, or an answer you need for a questionnaire. No license, meeting, or account first. If you are earlier than that, read E2EE changes your application architecture.