ATSAM Protocol: Raven's layered security architecture.

Notation

‖ is concatenation. LP(x) = uint16_be(|x|) ‖ x is a length-prefixed field. ∅ is the empty string. A is the initiator, B the responder. All HKDF is HKDF-SHA-256 (RFC 5869), extract-then-expand.

1. Two independent shared secrets

Each side computes a classical and a post-quantum secret. Both are 32 bytes.

Z_X   = X25519(sk_self , pk_peer)                    (RFC 7748)
Z_PQ  : (ct, Z_PQ) ← ML-KEM-768.Encaps(ek_B)          (FIPS 203, initiator)
        Z_PQ       ← ML-KEM-768.Decaps(dk_B, ct)      (FIPS 203, responder)

X25519 gives Z_X its security from the elliptic-curve Diffie–Hellman problem; ML-KEM-768 gives Z_PQ its security from Module-LWE, which is not known to fall to Shor's algorithm.

2. The transcript

Every value that influenced the handshake is bound into one hash. Every variable-length field is length-prefixed and every other field is fixed-width, so the encoding is injective: no two distinct field sequences serialise to the same byte string.

T  = D_transcript ‖ version ‖ suite
     ‖ LP(pk_A^X) ‖ LP(pk_B^X)
     ‖ LP(ek_A)   ‖ LP(ek_B)   ‖ LP(ct)
     ‖ LP(context) ‖ nonce₃₂
     ‖ LP(id_A)   ‖ LP(id_B)   ‖ hybridRequired

th = SHA-256(T)

Why the identities are in there. id_A and id_B are the two users' identifiers, placed in fixed initiator/responder slots. Without them, the same key material could be replayed across a different pair of people. With them, A and B must agree on who they think they are talking to or the transcripts differ, the roots differ, and every message fails to open. The protocol has no silent failure mode here — disagreement is fatal by construction.

3. The hybrid root key

K_root = HKDF-SHA256(
             IKM  = Z_X ‖ Z_PQ,          ← classical first, then post-quantum
             salt = th,
             info = "ATSAM/v1/pair-init" ‖ th,
             L    = 32 )

Why this is a genuine hybrid. Both secrets enter as a single input keying material. HKDF-Extract is a computational extractor over that concatenation, so if either half remains unknown to the adversary the extracted key — and therefore K_root — stays computationally indistinguishable from uniform. Formally:

Adv ≤ Adv_HKDF-PRG + min( Adv_X25519-DDH , Adv_ML-KEM-768-IND-CCA )

The min, rather than a sum, is what makes this a real hybrid. (The transcript hash in the salt slot provides binding, not secrecy — it is derived entirely from public values.) An attacker who breaks X25519 — including one holding a future quantum computer and a recording of today's traffic — still faces ML-KEM-768. An attacker who breaks ML-KEM still faces X25519. The construction degrades to the strength of the stronger surviving primitive, not the weaker one.

The transcript hash appears in both the salt and the info string. Either alone would bind the handshake; using both means a downgrade attempt has to defeat the extract stage and the expand stage.

4. The key tree

The root is never used directly. Each subsystem gets a labelled sub-key:

K_label = HKDF-SHA256( IKM = K_root , salt = ∅ , info = label , L = 32 )

Distinct labels — discovery, live confirmation, routing tags, message sealing — yield keys that are independent under the PRF assumption. Compromising a derived key does not reveal the root or any sibling key.

5. Sealing one message

seed  = HKDF-SHA256( K_root , info = "ATSAM/v1/msg-seal" )

K_msg = HKDF-SHA256(
            IKM  = seed,
            salt = "ATSAM/v1/msg-seal/salt",
            info = "ATSAM/v1/msg-seal" ‖ 0x00 ‖ sender ‖ 0x00 ‖ recipient ‖ 0x00 ‖ msgId,
            L    = 32 )

AAD   = SHA-256( "ATSAM/v1/msg-seal/aad" ‖ 0x00 ‖ version‖suite
                 ‖ 0x00 ‖ sender ‖ 0x00 ‖ recipient ‖ 0x00 ‖ msgId )

N     ←$ {0,1}⁹⁶
C ‖ τ = ChaCha20-Poly1305.Seal( K_msg , N , plaintext , AAD )     (RFC 8439)

Key separation per message. msgId is inside the info string, so every message derives a different K_msg. A nonce collision — catastrophic for ChaCha20-Poly1305 under a fixed key — would additionally require the same message identifier.

Directionality. sender and recipient occupy fixed ordered slots, so A→B and B→A derive different keys. A ciphertext reflected back at its author does not authenticate.

Injective encoding. Identifiers containing 0x00 are rejected before derivation, so the separator cannot be smuggled into a field to make two different triples produce identical info bytes.

Version binding. The version and cipher-suite bytes travel in clear on the wire and are bound into the AAD, so flipping them to steer a receiver onto a different suite invalidates the tag.

6. The safety number

The 30 digits you compare with a contact — six groups of five — are a deterministic function of K_root and the two identifiers in sorted order, so both sides compute the same string. Concretely: the root is passed through the key tree to its PV-Stealth lookup sub-key, that sub-key is hashed, the two sorted identifiers are appended, and the first 30 bytes of the SHA-512 digest are folded five at a time into six five-digit groups.

Because the identities are already bound into the transcript, a machine-in-the-middle who substituted a key produces a different root and therefore different digits. Comparing them out of band is what converts the protocol's mathematical guarantee into a guarantee about the human you meant to reach. Each group carries log₂(100000) ≈ 16.6 bits, so the comparison is worth roughly 100 bits against a second-preimage search — ample for an out-of-band check, and we quote that figure rather than the 240 bits of the underlying digest.

What this construction does not give you

A specification that only lists strengths is marketing, not cryptography. Three honest limits of the layer described above:

No forward secrecy in the message layer. K_msg is a deterministic function of a long-lived K_root and values that travel in clear. There is no ratchet. An adversary who later extracts K_root from a device can decrypt every archived message from that pair. Fresh per-message nonces do not provide forward secrecy, and we do not claim otherwise. Adding a ratchet to a delay-tolerant mesh — where messages legitimately arrive days late and out of order — requires a skipped-key window and an explicit epoch on the wire; it is scheduled work, not a shipped property.

Pairing must be completed deliberately. The guarantees above apply to a pair that has actually run the hybrid pairing exchange, which today means both people completing it from Settings → Security → Pair a device. Contacts you have not paired this way are protected by RAVEN's Noise-based layer instead — a different construction with different properties.

The post-quantum half can be absent. If either side lacks ML-KEM keys, pairing is refused by default. A caller may explicitly opt into an X25519-only mode in which Z_PQ is a fixed all-zero block; in that mode there is no post-quantum protection at all, and the root's security rests on X25519 alone.

Mathematics is not deployment. A correct construction can be let down by its implementation. RAVEN's security-critical source is published for exactly this reason, and findings sent to info@raven-messenger.com get an acknowledgement within 48 hours.