The mathematics behind the mechanisms.

A KEM establishes a shared secret

A key-encapsulation mechanism has three algorithms. The receiver creates a public/private key pair. The sender uses the public key to generate a ciphertext and a shared secret. The receiver uses the private key to recover that secret.

(pk, sk) ← KeyGen()
(ct, ss) ← Encaps(pk)
ss′      ← Decaps(sk, ct)

Correctness: ss′ = ss, except with the scheme's failure probability.

The ciphertext is safe to transmit under the KEM's security assumptions. The secret becomes input to key derivation; it is not the message itself. An unauthenticated public key can still belong to an attacker. FIPS 203 defines ML-KEM and its parameter sets.

In Auris: current first-contact prekeys use ML-KEM-1024; the continuing ratchet and hybrid inner transport use ML-KEM-768. The proposed v5 paper instead fixes an X-Wing profile using ML-KEM-768. Substituting 1024 into that paper is a new construction, not an editorial update.

Why hybrid does not automatically mean “either one”

A hybrid exchange combines classical and post-quantum inputs. A desired robustness statement says that one surviving component protects the result. To establish it, an analysis must specify who chooses each input, which keys can be compromised, what the attacker can query, and exactly how the combiner works.

The X-Wing paper proves results for its specific construction and assumptions. It does not prove arbitrary concatenation of secrets. Auris's deployed custom handshake retains a separate hidden-component extraction assumption; the broad historical active-security claim was refuted. The v5 conditional argument keeps the classical and active-quantum branches separate.

Confidentiality and authentication ask different questions

Confidentiality asks what an attacker learns. Authentication asks which peer participated, on which transcript, and when. A signature verifies a statement under a public key; a separate identity-binding mechanism must establish whose public key it is.

Auris pv4 signs the initiator transcript with Ed25519 and ML-DSA-65. The sealed envelope protects the identity-bearing material from the forwarding service, but the receiving peer obtains the signed statement. Sealing it does not make the statement deniable to that peer. The first directory lookup still needs a trusted identity check.

FIPS 204 specifies ML-DSA signatures. The safety-number guide explains Auris's user-visible identity check.

Extraction and expansion have different inputs

PRK = HMAC(salt, input key material)
T₁  = HMAC(PRK, info || 0x01)
T₂  = HMAC(PRK, T₁ || info || 0x02)
output = the required prefix of T₁ || T₂ || …

HKDF separates extraction of suitable key material from expansion into purpose-specific keys. The info value binds a use or context; unambiguous encoding prevents different contexts from accidentally sharing the same bytes.

The v5 R2 adapter uses an already pseudorandom X-Wing secret directly as the HMAC key for one expansion block. Its input includes a domain label, suite identifier, transcript hash and block counter. The paper's 77-byte HMAC input and 7,516-byte transcript are reproducible byte objects. This is different from the deployed handshake's extraction problem.

Forward secrecy looks backward; recovery looks forward

chain key at step i ──→ message key i
        │
        └─────────────→ chain key at step i+1

fresh, uncompromised exchange input + old root ──→ new root

Erasing earlier keys can limit what a later snapshot reveals about old messages. Deriving future keys from a stolen chain key does not repair the compromise. Recovery needs fresh input the attacker cannot compute and the protocol events that incorporate it.

In a KEM ratchet, encapsulating to an already stolen private key does not meet that requirement. Delivery and direction also matter: a sender's new chain and the peer's old sending chain can have different exposure. Retained skipped keys intentionally extend what can be decrypted after a snapshot.

The Double Ratchet specification is background reading. Its proofs do not transfer automatically to Auris's custom root-fold construction; Auris's directional argument remains a sketch with explicit gaps.

What a 128-bit random salt changes

Auris capability 7 derives message AEAD material from the message key and a fresh 16-byte salt. Consider q encryptions that repeat the same message key after rollback. If their salts are independent uniform 128-bit strings, a union bound gives:

Pr[at least one salt repeats] ≤ q(q − 1) / 2¹²⁹

q = 1,000,000  →  bound ≈ 1.47 × 10⁻²⁷

There are q(q−1)/2 pairs of salts, and each pair matches with probability 2⁻¹²⁸. This arithmetic is a bound on salt collisions only. It assumes fresh randomness; it does not account for failures of the KDF or AEAD. Different salts do not mathematically guarantee distinct derived outputs.

Salt does not protect a stolen message key, reject replay, restore lost messages or repair an invalid identity rollback. Nor does checking a derived commitment establish a full committing-AEAD theorem. See the actual mechanism.

A security game defines what “secure” means

A game fixes the attacker's interfaces and the event being tested. One indistinguishability convention measures how far a guess departs from a fair coin:

Advantage = | Pr[correct guess] − 1/2 |

Some papers multiply that quantity by two. Bounds cannot be compared without checking the convention, queries, resource limits and corruption rules.

Auris R2 tests a root before any artifact derived from that target root is exposed. Its system lift has the form Adv_real ≤ Adv_model + ε_sys. The paper does not establish that every event contributing to ε_sys is negligible. The theorem boundary must stay visible when discussing the first encrypted message or call keys.

Where to go deeper

Read the exact R2 scope, R3 symbolic model, evidence guide and primary-source reading list. They distinguish mathematical statements from implementation and deployment evidence.