Post-Quantum Cryptography Roadmap
Migration plan for gozzip's cryptographic primitives to post-quantum algorithms. Priority: 3/10 — plan now, act later.
Current Cryptographic Primitives
| Primitive | Algorithm | Usage | Key/Sig Size | Quantum Threat |
|---|---|---|---|---|
| Transport identity | Ed25519 | iroh EndpointId, peer authentication | 32B pub / 64B sig | Shor's algorithm breaks in poly-time |
| Event signing | secp256k1 | Nostr event signatures, author identity | 32B pub / 64B sig | Shor's algorithm breaks in poly-time |
| Content hashing | SHA-256 | Event IDs, integrity checks | 32B digest | Grover's algorithm halves security (128-bit effective) — still safe |
| Key exchange | X25519 | QUIC TLS 1.3 handshake (via iroh) | 32B | Shor's algorithm breaks in poly-time |
All signature and key exchange schemes are vulnerable to a sufficiently large quantum computer running Shor's algorithm. SHA-256 is weakened by Grover's algorithm but retains 128-bit security — acceptable.
Why Not Now
Five reasons to defer active PQ migration:
1. Public Data — No Harvest-Now-Decrypt-Later Threat
The primary quantum risk for classical crypto is HNDL: an adversary records encrypted traffic today and decrypts it when quantum computers are available. Gozzip gossip messages are public by design — there is nothing to harvest. The only encrypted channel is QUIC transport, which has forward secrecy (ephemeral keys per session). Recorded QUIC sessions cannot be decrypted even with the long-term private key.
2. No E2E Encryption Yet
Gozzip does not currently implement E2E encrypted DMs. When it does (NIP-44 + NIP-17, per ADR 012), PQ key exchange should be included from day one (see Tier 3 below). But until then, there is no encryption to protect.
3. iroh QUIC Has Forward Secrecy
Even if an adversary obtains a node's Ed25519 private key via a future quantum computer, they cannot decrypt past QUIC sessions. The ephemeral X25519 keys used per-session are not recoverable from the long-term key. The threat is limited to impersonation (forging new messages), not retroactive decryption.
4. PQ Crates Are Unaudited
The RustCrypto ML-KEM and ML-DSA implementations exist but have not undergone formal security audits. Deploying unaudited PQ crypto could introduce implementation vulnerabilities worse than the theoretical quantum threat.
5. Protocol Is Pre-v1.0
Wire format changes are still free. Adding PQ-ready type enums now (Tier 0) costs nothing and preserves the ability to add PQ algorithms without a breaking change later.
Threat Model: What Quantum Breaks
| Attack | Requires | Timeline Estimate | Impact on Gozzip |
|---|---|---|---|
| Forge Ed25519 signatures | Real-time quantum computer | 2035-2045+ | Impersonate iroh peers |
| Forge secp256k1 signatures | Real-time quantum computer | 2035-2045+ | Forge Nostr events, steal identity |
| Break X25519 key exchange | Real-time quantum computer | 2035-2045+ | MITM future QUIC sessions (not past — forward secrecy) |
| Brute-force SHA-256 | Grover's algorithm | Impractical (2^128 operations) | No practical impact |
| Decrypt recorded QUIC traffic | Quantum computer + recorded traffic | N/A — forward secrecy prevents this | No impact |
The primary risk is identity theft — an adversary with a quantum computer could forge signatures to impersonate any Nostr identity. This requires a real-time, fault-tolerant quantum computer, estimated at 2035-2045 at the earliest.
NIST Post-Quantum Standards
Adopt
| Standard | FIPS | Type | Primitive | Key Size | Sig/Ciphertext Size | Basis |
|---|---|---|---|---|---|---|
| ML-KEM | FIPS 203 | Key Encapsulation | Kyber (lattice) | 800-1568B | 768-1568B | Module-LWE |
| ML-DSA | FIPS 204 | Digital Signature | Dilithium (lattice) | 1312-2592B | 2420-4595B | Module-LWE + SIS |
| SLH-DSA | FIPS 205 | Digital Signature (backup) | SPHINCS+ (hash) | 32-64B | 7856-49856B | Hash-based (conservative) |
ML-DSA is the primary signature target — smallest PQ signatures with fast verification. SLH-DSA is the conservative backup — hash-based security assumptions are better understood than lattice assumptions, but signatures are 10-20x larger.
Rust Crates
| Crate | Algorithm | Maintainer | Status |
|---|---|---|---|
ml-kem |
ML-KEM (FIPS 203) | RustCrypto | Implemented, unaudited |
ml-dsa |
ML-DSA (FIPS 204) | RustCrypto | Implemented, unaudited |
slh-dsa |
SLH-DSA (FIPS 205) | RustCrypto | Implemented, unaudited |
rustls-post-quantum |
Hybrid PQ key exchange for TLS | rustls project | Experimental |
Migration Tiers
Tier 0: PQ-Ready Type System (Now)
Cost: Low. Dependency: None.
Evolve fixed-size key and signature types into enums before v1.0 to avoid a breaking wire format change later.
// Before: fixed-size, algorithm-locked
pub type PubKey = [u8; 32];
pub type Signature = [u8; 64];
// After: extensible, algorithm-agnostic
#[derive(Serialize, Deserialize)]
pub enum CryptoKey {
Ed25519([u8; 32]),
Secp256k1([u8; 32]),
// Future:
// MlDsa44([u8; 1312]),
// MlDsa65([u8; 1952]),
}
#[derive(Serialize, Deserialize)]
pub enum CryptoSignature {
Ed25519([u8; 64]),
Secp256k1([u8; 64]),
// Future:
// MlDsa44(Vec<u8>), // 2420 bytes
// MlDsa65(Vec<u8>), // 3293 bytes
}
The enum discriminant adds 1 byte of wire overhead (postcard varint encoding). Verification dispatches on the variant. This is a prerequisite for all subsequent tiers.
Tier 1: Wait for iroh PQ-Hybrid QUIC (Free)
Cost: Zero. Dependency: iroh + rustls ecosystem.
The rustls project is working on post-quantum hybrid key exchange for TLS 1.3 (X25519 + ML-KEM). When iroh upgrades its QUIC implementation (quinn, which uses rustls), gozzip gets PQ transport encryption for free — no code changes required.
This protects against future quantum MITM attacks on QUIC connections. It does NOT protect Nostr event signatures (those require Tier 2).
Track: rustls-post-quantum crate progress and iroh release notes.
Tier 2: Optional ML-DSA Signatures (When Audited)
Cost: Medium. Dependency: Audited ml-dsa crate.
Add ML-DSA event signatures behind a feature flag:
[features]
post-quantum = ["ml-dsa"]
- Nodes with
post-quantumenabled sign events with both secp256k1 AND ML-DSA (dual signature). - Nodes without the flag ignore the ML-DSA signature and verify only secp256k1.
- Dual signatures ensure backward compatibility during transition.
- ML-DSA-44 adds ~2420 bytes per event signature. Acceptable for text events, notable for high-frequency event types.
Trigger: Deploy when the ml-dsa crate passes a formal security audit by a recognized firm (e.g., NCC Group, Trail of Bits, Cure53).
Tier 3: Hybrid ML-KEM + X25519 Key Exchange (When E2E DMs Ship)
Cost: Medium-high. Dependency: E2E DM implementation (NIP-44 + NIP-17) + audited ml-kem crate.
When gozzip implements E2E encrypted direct messages, the key exchange MUST use a hybrid scheme from day one:
- Perform X25519 ECDH (classical).
- Perform ML-KEM encapsulation (post-quantum).
- Combine both shared secrets via HKDF to derive the message encryption key.
This ensures that even if ML-KEM is later found to have a flaw, X25519 still protects the conversation. And even if quantum computers break X25519, ML-KEM protects the conversation. Both must be broken simultaneously.
Do NOT ship classical-only E2E DMs. Unlike public gossip messages, DM content is private and subject to HNDL attacks. An adversary who records the key exchange today could decrypt the conversation with a future quantum computer if only X25519 is used.
Why NOT SIDH
Supersingular Isogeny Diffie-Hellman was xx.network's quantum-resistant key exchange. In August 2022, Wouter Castryck and Thomas Decru published an attack that recovers SIDH private keys for all standardized parameter sets (SIKEp434, SIKEp503, SIKEp610, SIKEp751) in hours on a single laptop core.
The attack exploits the auxiliary torsion point information that SIDH publishes as part of the public key. This is a fundamental protocol flaw, not an implementation bug — no parameter choice can fix it.
NIST had already advanced SIKE (SIDH's KEM variant) to Round 4 of the PQ competition before the break. It was immediately withdrawn. Any system still using SIDH/SIKE is using broken cryptography.
Why NOT WOTS+
Winternitz One-Time Signatures are hash-based and quantum-resistant, but fundamentally incompatible with gozzip's requirements:
-
One-time use: Each WOTS+ keypair can sign exactly one message. Signing a second message with the same key leaks the private key. Nostr identities sign thousands of events over their lifetime.
-
Large signatures: WOTS+ signatures are 2-8KB depending on the Winternitz parameter. Compare to 64 bytes for Ed25519/secp256k1. Every gossip message would carry 30-125x more signature data.
-
Key management complexity: A node would need to pre-generate and manage thousands of one-time keypairs, track which have been used, and securely delete spent keys. This is fragile and error-prone.
-
No identity continuity: The "public key" changes with every signature. There is no persistent identifier to put in a Nostr profile or WoT graph. The entire identity model breaks down.
SLH-DSA (SPHINCS+, FIPS 205) solves these problems — it is hash-based and quantum-resistant like WOTS+ but supports unlimited signatures per keypair, at the cost of larger signature sizes (7-50KB). It remains gozzip's conservative backup if lattice-based ML-DSA is ever compromised.