Pre-use root secrecy
A Conditional Proof of Pre-Use Root Key Indistinguishability for the Auris v5 Handshake, revision 1.16. A narrow mathematical result for a frozen candidate, with a public paper and reproduction bundle.
The publication record
Max Von, The Auris Project. The Zenodo record identifies revision 1.16 with publication date July 22, 2026 and version DOI 10.5281/zenodo.21486656. The record, filenames, sizes and archive checksums were reconfirmed through the repository API on September 5. Local copies match those recorded checksums.
Read revision 1.16
The conditional argument, definitions, resource ledger and exclusions.
Artifact · ZIP · 539 KBReproduce the vectors
Frozen source, expected outputs and verification instructions from the public archive.
An ePrint submission is recorded internally. No public ePrint report number was confirmed in this review, so the archive is not described as an ePrint publication. Public deposit is also not peer review. Independent human expert review is not established; the project discloses extensive machine-assisted authoring and review.
Which construction?
The paper’s v5 candidate uses the exact X-Wing hybrid KEM from frozen draft 10, combining ML-KEM-768 and X25519. It has a separate initial-ratchet X25519 prekey and a strict 44-field, 7,516-byte transcript. This is neither the released pv4 first-contact protocol nor the hybrid inner transport.
X-Wing has its own published analysis. Its draft 10 is the pinned source here; an Internet-Draft is not a final RFC. A future draft change would require checking whether the imported statement and bytes still match.
The exact root derivation
Let τ be the frozen transcript and ss the 32-byte X-Wing shared secret. The candidate uses one HKDF-Expand block, with that secret directly in the PRK/key position:
H_T(τ) = SHA-384("auris/handshake-transcript/v5" || 0x00 || τ)
info = "auris/root/v5/xwing-d10" || 0x00
|| UINT32BE(0x00050001) || H_T(τ)
root = HMAC-SHA-256(ss, info || 0x01)
The HMAC message is 77 bytes: 23 domain bytes, one separator, four suite bytes, 48 transcript-hash bytes and one block counter. This is a definition of the frozen construction, not advice to change the released protocol. RFC 5869 distinguishes extraction from expansion; the paper must justify its direct-use premise for the KEM output.
What the argument claims
The test occurs at ROOTREADY, before any root-derived artifact is exposed. Revision 1.16 states two separate conditional results: an active-quantum branch relying on the surviving ML-KEM-side assumptions, and an active-classical branch relying on its specified X25519 fallback assumptions. Both include additional binding, hash/KDF, adapter and execution-model premises. The paper’s exact statements and resource ledger are authoritative.
The multi-target accounting uses N_T = N_K × N_S for its key/session slots. Lifting a primitive-level result into the surrounding system retains an explicit system-failure term. This review does not establish that term is negligible for Auris, and a reproducible vector cannot establish the underlying computational assumptions.
The boundary matters
- The paper rejects the merged active-attacker claim that simply says “either component holds.” The two branches cannot be silently combined into that broader theorem.
- A raw-root real-or-random test after a root-derived AEAD artifact becomes visible is explicitly outside the valid pre-use claim. Operational key separation and first-use composition need their own argument.
- The ratchet, calls, state persistence, identity system, recovery and implementation conformance are not proved by this result.
- The candidate is research. Its mathematical status does not certify the released beta.
Reproduction and provenance
The public bundle’s runner defaults to verification in a temporary directory, comparing fresh generated objects against frozen artifacts. It requires a C compiler, Python and an OpenSSL build with ML-KEM support. Read the bundle’s instructions and run reproduction/run_all.sh without the authoring-only --update option.
The documentation review reruns the repository’s frozen revision-1.16 reproduction suite and separately checks publication metadata. This verifies selected bytes and artifact consistency, not the correctness of every proof step. The PDF SHA-256 is:
2a025e6026df53a5f2365116e39a0897964cba338dc4c00db104a3dde53af594
For the broader evidence distinctions, see how to read the evidence.
Reviewed · Review scope and versions