Protocol PHANTOM
Research specification for an asynchronous post-quantum transport design over onion-routed networks. The current document is a technical baseline; formal evaluation remains incomplete.
This specification describes a cryptographic protocol in the theoretical design phase (current baseline SPEC-000). It includes revisions for identified issues involving post-quantum KCI, PIR index collisions, and padding side channels. It must not be deployed in production without formal verification in Tamarin or ProVerif and independent code review.
1. Adversary Model & Security Perimeter
The protocol does not assume unconditional resistance against state-level adversaries. Instead, it is formally defined against an active and passive adversary with global network control capabilities (Extended Dolev-Yao) under four concrete parameters and a bounded security perimeter:
- Infrastructure ControlActive control of up to 30% of overlay network nodes (Tor/Mixnet).
- Statistical AnalysisIAT classifiers based on Transformer architecture for global traffic.
- Indefinite Capture (HNDL)Mass storage under Harvest-Now-Decrypt-Later for future decryption.
- Quantum Capability (CRQC)Access to a Quantum Computer in polynomial time for discrete logarithm and factorization.
- Endpoint IntegrityAbsolute integrity of endpoint devices is assumed, with no kernel-level malware compromise.
- Out-of-Band Channel (OOB)Confidentiality and authenticity of the out-of-band verification channel are assumed at pairing time.
- Symmetric DeniabilityAll protocol deniability is delegated to the construction of ephemeral symmetric secrets.
2. Cryptographic Stack & Hybrid Primitives
The cryptographic layer uses a hybrid post-quantum/classical design combining lattice-based primitives (ML-KEM-768, FIPS 203; ML-DSA-87, FIPS 204) with pre-quantum elliptic-curve primitives (X25519, RFC 7748). The symmetric transport uses authenticated encryption ChaCha20-Poly1305 with domain-separated key expansion via HKDF-HMAC-SHA3-256.
| Function / Layer | Standard Primitive | Base Standard | Role in Protocol | Evidence Level |
|---|---|---|---|---|
| Post-Quantum KEM | ML-KEM-768 | FIPS 203 | Hybrid encapsulation and session establishment | Level 1 (NIST Standard) |
| Pre-Quantum KEM | X25519 | RFC 7748 | Residual classical security and elliptic binding | Level 3 (IETF RFC) |
| Post-Quantum Signature | ML-DSA-87 | FIPS 204 | Handshake authentication and long-term identity key | Level 1 (NIST Standard) |
| Symmetric AEAD Cipher | ChaCha20-Poly1305 | RFC 8439 | Authenticated protection of transport cells | Level 3 (IETF RFC) |
| Key Derivation (KDF) | HKDF-HMAC-SHA3-256 | RFC 5869 / FIPS 202 | Extraction and expansion with strict domain separation | Level 3 (IETF RFC) |
3. Handshake v2 & Post-Quantum Anti-KCI Authentication
To mitigate the cryptographic vulnerability of version v0.1.0 (where the lack of origin authentication in the post-quantum KEM allowed KCI impersonation attacks via CRQC), Handshake v2 enforces active origin authentication using ML-DSA-87 signatures.
PrekeyBundle_B (Bob)Total: 8,437 Bytes
- version (u16)0x0002 (2 B)
- IK_B (X25519 Identity)32 B
- PQ_IK_B (ML-DSA-87 Public)2,560 B
- SPK_B (X25519 Ephemeral)32 B
- SPK_B_sig (ML-DSA-87 signature over SPK_B)4,627 B
- PQ_PK_B (ML-KEM-768 Public)1,184 B
Initialization flow
- Step 1 — Generation (Alice):
Generates EK_A and PQ_EK_A, then computes (ct_PQ_B, ss_PQ_B) = Encaps(PQ_PK_B), the X25519 values dh1, dh2, dh3, and a transcript signature. - Step 2 — Validation and response (Bob):
Bob verifies Sig_A with PQ_IK_A, decapsulates ss_PQ_B, and produces (ct_PQ_A, ss_PQ_A) = Encaps(PQ_PK_A).
Session master-key derivation (SPEC-000 §3.2)
4. Split-ratchet mechanism
The proposed split ratchet separates symmetric-chain updates from post-quantum asymmetric steps. In this design, the asymmetric exchange occurs when the communication direction changes.
State structure (RatchetState §4.1)
Unidirectional symmetric transition (§4.2)
For consecutive sends without a response, only the HKDF symmetric chain advances; no per-message asymmetric operation is specified.
5. Private Storage Network & SimplePIR Epochs
To resolve the desynchronization and index-collision problems of version v0.1.0, the storage network abandons real-time indexing over dynamic matrices and adopts a Time-Structured Frozen Epochs architecture.
Frozen Epochs Mechanism (§5.1)
The relay database is frozen at discrete intervals of Δt = 300 seconds. During an active epoch, write requests (StoreRequest) are stored in a temporary buffer indexed by:
At epoch close, the server compiles a static matrix sorted lexicographically by message_id and publishes its root hash.
Private Retrieval with SimplePIR (§5.2)
Estimating that its message belongs to Epoch E_n, the receiver downloads the binary metadata map and identifies the exact row.
The design runs the SimplePIR query over a static matrix so the client and server can derive the same row layout despite concurrent writes being buffered elsewhere.
6. Transport Layer & DP-Adaptive Padding
To prevent pattern detection caused by large-payload fragmentation, the specification radically alters cell parameters in the overlay network:
Maximum Transmission Unit (MTU §6.1)
The fixed cell size is set immutably to S_cell = 2048 bytes. Every control packet, handshake, or short message is padded with pseudo-random bytes (sequential encryption of 0x00) to reach exactly 2048 bytes before being injected into the Loopix Sphinx circuit.
Differential Privacy Injection (Laplace Engine §6.2)
The engine evaluates the queue at strict intervals of T_slot = 50 ms. The global adversary's advantage in determining whether a slot contains real or cover traffic is bounded by:
This bound is a design target pending a public analysis; it has not been demonstrated for an implementation.
If the queue is empty, an indistinguishable synthetic cell generated via local CSPRNG is injected.
7. OOB verification and anti-abuse proof of work
Out-of-band verification (OOB SAS §7)
After the handshake, the session remains in STATUS_AWAITING_VERIFICATION. Moving to STATUS_ACTIVE requires:
Comparison of an eight-digit SAS and mutual QR scanning tied to the transcript and proposed PQ identities.
Argon2id request cost (§8)
Because IP or circuit identity is not a stable rate-limit key for onion services, the design assigns a memory-hard proof-of-work cost to each StoreRequest:
This is an abuse-cost mechanism, not a proof that denial-of-service is prevented.
1. Deterministic 7-Phase Research Lifecycle
Every architectural evolution in PHANTOM follows a strict 7-phase methodology. Advancing between phases requires meeting explicit exit criteria. Qualitative assessments are not accepted; validation requires mathematical proofs, formal models (Tamarin / ProVerif), or reproducible empirical simulations.
| Phase | Phase Objective | Artifact Pattern | Exit Criterion |
|---|---|---|---|
| Phase 1 | Research Questions | RQ-XXX | Formulation of verifiable security hypotheses |
| Phase 2 | Literature & Notes Review | LR-XXX / LN-XXX | Cataloging against the Evidence Hierarchy (Levels 1–7) |
| Phase 3 | Architectural Decisions | ADR-XXX | Mandatory analysis of counter-evidence and trade-offs |
| Phase 4 | Threat Models | TM-XXX | Formal delimitation of boundaries and attacker scope |
| Phase 5 | Technical Specifications | SPEC-000 (v0.2.0) | Immutable Evaluation Baseline |
| Phase 6 | Formal Proofs & Experiments | VER-XXX / EXP-XXX | Tamarin / ProVerif models and simulation metrics |
| Phase 7 | Publications & Monograph | PUB-XXX | Peer-reviewed research articles |
2. Cryptographic Evidence Hierarchy (Levels 1–7)
Each primitive, parameter, and theoretical claim must be explicitly linked to a source cataloged according to the project's governance standards:
| Level | Source Category | Examples & Standards Included |
|---|---|---|
| Level 1 | International / Government Standards | ISO, IEC, IEEE, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) |
| Level 2 | Reference Special Publications | NIST SP 800 Series, IETF Standards Track RFCs |
| Level 3 | Consolidated Internet Standards | Active RFCs (RFC 7748, RFC 8439, RFC 5869) |
| Level 4 | Active Technical Drafts | IETF Internet-Drafts |
| Level 5 | Research literature and preprints | IACR ePrint (preprints without peer review); peer-reviewed publications indexed by IEEE Xplore, ACM DL, USENIX and NDSS. |
| Level 6 | Official Code & Documentation | Project documentation, repositories and verified executables |
| Level 7 | Verifiable Grey Literature | Independent audit reports, industry white papers |
3. Human Operator Primacy & Audit Rules
Human Authorship & Manual Verification Rule (GOVERNANCE §3)
Core research tasks—including primary literature reading, RQ formulation, cryptographic flaw identification, and specification drafting—are directed and executed directly by the human operator (Eduardo Camarillo [Noir0x63]).
Manual Verification Rule: No claim, formula, or architectural decision suggested or assisted by AI tools is accepted into the baseline without direct manual verification against primary sources (Levels 1–7).
Counter-Evidence Analysis & Retrospective Audit (§4–§5)
Counter-Evidence Analysis: Each Architectural Decision Record (ADR) requires actively investigating published theoretical attacks, latency/CPU/RAM/bandwidth penalties, and edge-case failure points.
Retrospective Audit: If an audit detects a break in the traceability chain PUB → SPEC → TM → ADR → LR → LN → Primary Source, the affected component is invalidated immediately and reverted.