> For the complete documentation index, see [llms.txt](https://wiki.gen6.life/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.gen6.life/technology-core/standards/ggs-6-post-quantum-infrastructure.md). # GGS-6: Post-Quantum Infrastructure **Applies to:** Gen6 chain (Substrate-based, Enhanced Proof of Authority), RealSeal, NCrypt, GSX account keys. **External baseline:** NIST FIPS 203 / 204 / 205 (finalized 13 August 2024). *** ### 0. Scope This standard specifies which post-quantum cryptographic (PQC) algorithms Gen6 adopts, where each applies across the stack, and the phased engineering plan to migrate the live chain, RealSeal, and NCrypt to post-quantum security. Gen6's current cryptographic primitives, confirmed from the codebase and used as the migration baseline throughout this document: | Layer | Current primitive | Type | PQC status | | ------------------------------- | ---------------------------------------- | -------------------------------- | ------------------------------------- | | Gen6 Infrastrucutre Management | mlkem768x25519-sha256 | SSH | **PQC** | | RealSeal / RealSeal IoT hashing | BLAKE2 / BLAKE3, SHA-256 | Hash | **Quantum-acceptable** | | NCrypt payload encryption | ChaCha20-Poly1305 | Symmetric AEAD | **Quantum-acceptable at 256-bit key** | | NCrypt key exchange | X25519 (Curve25519) | Key exchange | PQC to add. | | NCrypt sender authentication | Ed25519 | Signature (EdDSA) | PQC to add. | | GSX account signatures | sr25519 | Signature (Schnorr/EdDSA family) | PQC to add. | | RealSeal signature | Ed25519 / sr25519 (chain signature) | Signature | PQC to add. | | Consensus (Enhanced PoA) | Substrate primitives (Ed25519 / sr25519) | Signature | PQC to add. | The migration priority: the **public-key components (X25519 key exchange, Ed25519/sr25519 signatures) are the entire problem**. The symmetric and hashing primitives (ChaCha20-Poly1305, SHA-256, BLAKE2/BLAKE3) are quantum-acceptable at their current parameters and are retained. ### 1. Threat Model and Rationale #### 1.1 What quantum computing breaks in Gen6 * **Broken (public-key):** every Gen6 signature and key-exchange primitive - X25519, Ed25519, sr25519 - rests on elliptic-curve hardness and is broken by Shor's algorithm on a sufficiently large quantum computer. These are the highest-risk components. * **Weakened but acceptable (symmetric / hash):** ChaCha20-Poly1305, SHA-256, and BLAKE2/BLAKE3 are only weakened by Grover's algorithm, which halves effective security. At 256-bit keys / 256-bit output this leaves \~128-bit post-quantum strength, which is strong in practice. These are retained without change. Per the Web3 Foundation roadmap, the hash functions used at the Substrate consensus layer are likewise considered post-quantum secure. #### 1.2 Two distinct risks; different urgency * **Confidentiality → Urgent (Harvest-Now-Decrypt-Later).** NCrypt's X25519 key exchange is the critical exposure. An adversary can capture NCrypt ciphertext today and decrypt it once a quantum computer exists. Any NCrypt message with a multi-year confidentiality requirement is **already** at risk. This cannot wait for quantum hardware to actually arrive. * **Authentication → Must be ready before quantum, low pre-quantum exposure.** A forged signature (validator, account, RealSeal) only has value at the moment it is produced. As the Web3 Foundation researchers put it, for authentication "you just need to be far enough ahead to rotate the key." Signature migration must be complete before cryptographically-relevant quantum computers exist, but running Ed25519/sr25519 today leaks nothing. **Consequence:** NCrypt key exchange migrates to hybrid PQC first (Phase 1). Signature migration (account, RealSeal, consensus) follows on a deliberate, tested schedule (Phases 2–3). #### 1.3 Timeline posture Gen6 makes no claim about when cryptographically-relevant quantum computers arrive; no published estimate places them within the current decade with confidence. The rationale for acting now is HNDL exposure on NCrypt confidentiality plus the multi-year lead time to migrate a live chain safely. NSA CNSA 2.0 sets 2030 as the migration deadline for US national-security systems (specifying ML-KEM-1024 and ML-DSA-87); Gen6 treats 2030 as a reasonable "substantially complete by" anchor given its positioning toward government and defense buyers. ### 2. Algorithm Selection Gen6 standardizes on the NIST-finalized lattice family, matching the Web3 Foundation's choices for Polkadot so Gen6 stays aligned with its upstream Substrate framework rather than forking onto a bespoke cryptographic stack. #### 2.1 Signatures
PrimitiveNIST standardBasisGen6 roleRationale
ML-DSA (CRYSTALS-Dilithium)FIPS 204Module-LWE / Module-SIS (lattice)Default for consensus/authority signing, RealSeal signing, and NCrypt sender authenticationConstant-time implementation; NIST's recommended default signature. Matches the Web3 Foundation choice of Dilithium for validator signatures precisely because it is constant-time. Signature size 2420–4595 bytes.
FN-DSA (Falcon)FIPS 206 (draft)NTRU latticeGSX account signatures (user-held keys)Small signatures (~666 bytes) minimize on-chain transaction cost. Matches the Web3 Foundation choice of Falcon for accounts. Confined to account keys only — Falcon is not constant-time and is sampling-sensitive, so it is never used for consensus.
SLH-DSA (SPHINCS+)FIPS 205Hash-based (no lattice assumption)Long-lived / high-assurance RealSeal attestationsConservative fallback with a security assumption independent of lattices. Large signatures (7856–49856 bytes) and slow signing (~274 ms/sign, SHA2-128s, liboqs on Apple M-series), so used selectively where assumption diversity is worth the cost — e.g. archival or government evidence meant to verify for decades.
**Selection rule (per NIST guidance):** ML-DSA is the default signature everywhere unless a specific constraint justifies otherwise — signature size drives the Falcon choice for accounts; assumption diversity drives the SLH-DSA option for long-horizon RealSeal. Choice follows function, not preference. #### 2.2 Key Encapsulation (NCrypt) | Primitive | NIST standard | Basis | Gen6 role | | --------------------------- | ------------- | -------------------- | ------------------------------------------------------ | | **ML-KEM** (CRYSTALS-Kyber) | FIPS 203 | Module-LWE (lattice) | NCrypt key establishment, in a **hybrid** construction | Baseline parameter set: **ML-KEM-768** (Category 3, \~AES-192-equivalent) for NCrypt session establishment; **ML-KEM-1024** available for high-assurance contexts. ML-KEM public keys are 800–1568 bytes, ciphertexts 768–1568 bytes. ML-KEM-768 in hybrid with X25519 is the same construction deployed by Chrome and major TLS stacks, giving Gen6 a well-trodden reference path. #### 2.3 Hybrid mandate for NCrypt confidentiality For **all NCrypt key exchange**, Gen6 mandates a **hybrid** construction during the transition era: the existing **X25519** exchange runs in parallel with **ML-KEM-768**, and the two shared secrets are combined through a KDF so the session is secure if *either* primitive holds. Rationale: NIST's post-quantum KEMs have had far less side-channel cryptanalysis than X25519, so a hybrid construction ensures that a flaw in either the lattice scheme or the elliptic-curve scheme does not by itself break confidentiality. Pure-PQC (non-hybrid) key exchange is **not** adopted for NCrypt in this phase. #### 2.4 Symmetric and hash primitives — retained * **NCrypt payload encryption:** ChaCha20-Poly1305 is retained. It is a 256-bit-key AEAD; Grover leaves \~128-bit post-quantum strength, which is strong in practice. No change required. * **Hashing (RealSeal, RealSeal IoT, chain):** BLAKE2/BLAKE3 and SHA-256 are retained. Quantum-acceptable at 256-bit output. SNARK-friendly hashing (e.g. Poseidon) is introduced only where account-migration mechanics require it (see 3.4). #### 2.5 Explicitly not chosen * **QKD / hardware pQKD:** not adopted. Distance-limited, hardware-dependent, unnecessary given software PQC. * **Pure-PQC (non-hybrid) key exchange:** deferred until ML-KEM side-channel analysis matures. Hybrid only, for now. ### 3. Where Each Algorithm Applies #### 3.1 Consensus / authority layer (Enhanced Proof of Authority) Gen6 runs **Enhanced Proof of Authority (EPoA)**, not stake-weighted BABE + GRANDPA. This materially simplifies the consensus-layer migration relative to Polkadot's roadmap: * **Authority signing → ML-DSA (Dilithium).** All authority-signed consensus messages migrate from the current Ed25519/sr25519 primitive to ML-DSA, chosen for its constant-time property. * **VRF-based leader election is a BABE construct and does not apply to EPoA in the same way.** The hardest single item in the Polkadot roadmap — replacing stake-weighted VRF block production with a hash-based randomness beacon — is **largely not applicable to Gen6's PoA model**, since authority-set block production does not rely on the same VRF leader lottery. Any randomness Gen6's EPoA does use must be inventoried in Phase 0 and, if a quantum-vulnerable VRF is present, replaced with a hash-based construction; but Gen6 does not inherit BABE's full VRF-migration problem. This is a genuine structural advantage of EPoA for PQC migration. #### 3.2 GSX accounts * **Account signatures → FN-DSA (Falcon)** for new post-quantum accounts, chosen for small signature size to minimize transaction cost. * Existing accounts migrate via the mechanism in 3.4. #### 3.3 RealSeal (content signing) * **Hashing → BLAKE2/BLAKE3, retained** (quantum-acceptable). No migration needed for the hash layer. * **Signing → ML-DSA (Dilithium)** as the default, migrating from the current Ed25519/sr25519 chain signature. This is the primitive that cryptographically binds a BLAKE3 digest to a self-sovereign identity, and it is the quantum-vulnerable part of RealSeal that must move. * **Long-lived / high-assurance attestations → SLH-DSA (SPHINCS+)** optionally, where a non-lattice assumption is valuable. This ties directly to Gen6's permanent-record positioning: an attestation meant to remain verifiable for 30+ years is exactly where a conservative hash-based signature assumption justifies its larger size. * RealSeal IoT inherits the same hashing (retained) and signing (→ ML-DSA) migration as RealSeal. #### 3.4 Account migration (FRI-SNARK proof of seed knowledge) The mechanism that lets existing users move to PQC keys **without a pre-existing PQC key and without exposing their old private key** — essential because a live chain cannot force every holder to act at once. Following the Web3 Foundation design (adapted from Buterin's quantum-emergency hard-fork proposal): 1. Keys derived from a seed via hash-based HD derivation are post-quantum secure at the derivation step, even though the resulting curve private key is not. 2. The user submits a post-quantum FRI-based SNARK (a signature of knowledge, hundreds of KB) proving they know the seed that hashes to the existing account's key, and binding a new Falcon public key to that seed. 3. On acceptance, the chain transfers balance/authority from the old account to the new PQC account. Properties: the large proof is submitted once per account (size acceptable); hash-based derivation lets many existing cold wallets migrate without pre-provisioned PQC keys. **Gen6 posture:** adopt the upstream Substrate/Polkadot FRI-SNARK migration implementation when available rather than building bespoke. FRI-based SNARKs are fast-moving; the Web3 Foundation notes current implementations were written for Ethereum scaling and often neglect zero-knowledge, so the tooling will improve over the migration window. #### 3.5 NCrypt (messaging) * **Key establishment → hybrid X25519 + ML-KEM-768** (2.3). Highest priority in the standard due to HNDL. * **Sender authentication → ML-DSA (Dilithium)**, migrating from Ed25519, aligning NCrypt sender-auth with the account/identity signature migration. * **Payload encryption → ChaCha20-Poly1305, retained** (256-bit, quantum-acceptable). #### 3.6 Bridges / cross-chain Gen6's bridge configuration is not documented in the wiki. If Gen6 operates bridges, the Web3 Foundation's post-quantum BEEFY approach applies: authorities sign finality messages under each PQC scheme the target network supports, so a bridged chain can verify with whatever single PQC scheme it supports natively. If Gen6 has no bridges, this section is not applicable. Confirm bridge scope during Phase 0 and mark this section accordingly. #### 3.7 Transport (node-to-node) Adopt hybrid PQC key exchange feeding audited external post-quantum TLS libraries, per the Web3 Foundation roadmap. Do not hand-roll transport crypto — use audited libraries (4.5). *** ### 4. Development Plan Phased by the urgency logic in 1.2: confidentiality first, then signatures, then account migration and consensus, then cleanup. Phase 0 (discovery/agility/audit) runs first and continuously. #### Phase 0 — Inventory, crypto-agility, audit baseline *(prerequisite)* **Goal:** lock down exactly what Gen6 uses and make primitives swappable. * Complete the **cryptographic inventory** started in Section 0: confirm every signature, KEM, hash, and symmetric primitive across chain, RealSeal, RealSeal IoT, NCrypt, GSX, transport, and bridges. Commit it to the wiki as canonical. Two specific open items to close: (a) whether EPoA uses any quantum-vulnerable VRF/randomness primitive; (b) whether Gen6 operates any bridges. * Introduce **crypto-agility**: reference all primitives through an abstraction (algorithm identifiers / trait objects) so schemes swap without rewriting call sites. If the codebase hard-codes X25519/Ed25519/sr25519 at call sites, this refactor gates everything else. * Stand up **PQC test vectors in CI**: integrate a vetted PQC library (4.5) and validate against NIST FIPS 203/204/205 known-answer tests. **Exit criteria:** inventory ratified on wiki; every primitive swappable; PQC library in CI with passing KATs; EPoA-VRF and bridge questions answered. #### Phase 1 — NCrypt hybrid key exchange *(highest urgency: HNDL)* **Goal:** close the harvest-now-decrypt-later exposure. * Implement **hybrid key establishment**: run existing X25519 in parallel with **ML-KEM-768**, combine both shared secrets via KDF. * Confirm NCrypt payload uses **256-bit ChaCha20-Poly1305** (retained; raise only if any 128-bit path exists). * Ship as **backward-compatible negotiation**: hybrid where both peers support it, classical fallback only where a peer has not upgraded, with a published classical-only sunset date. * Version the NCrypt wire format so hybrid vs. classical is explicit and auditable. **Exit criteria:** new NCrypt sessions negotiate hybrid X25519 + ML-KEM-768 by default; downgrade-resistance tested; sunset date published. #### Phase 2 — RealSeal and GSX signature migration *(deliberate pace)* **Goal:** post-quantum signing for content and accounts, with dual-signature continuity. * Add **ML-DSA (Dilithium)** as a supported RealSeal signing scheme; make it default for **new** RealSeal and RealSeal IoT attestations. Retain verification of legacy Ed25519/sr25519 signatures for existing proofs. * Add optional **SLH-DSA (SPHINCS+)** for long-lived / high-assurance RealSeal attestations. * Introduce **FN-DSA (Falcon)** account keys for **new** GSX accounts. * Support a **dual-sign transition window** (classical + PQC) so verifiers upgrade before signers drop the classical signature. Nothing in migration may invalidate a previously valid RealSeal record — permanence is a core Gen6 property, so legacy verification is retained indefinitely. **Exit criteria:** new accounts and new RealSeal attestations PQC-signed; dual-sign verification live; legacy verification retained. #### Phase 3 — Account migration + EPoA consensus signing *(adopt upstream)* **Goal:** move existing accounts to PQC and make consensus signing post-quantum. * Implement the **FRI-SNARK seed-knowledge account migration** (3.4) once the upstream implementation is available; expose a one-time "migrate to PQC" user flow. * Migrate **EPoA authority signing to ML-DSA (Dilithium)**. * If Phase 0 found a quantum-vulnerable VRF/randomness primitive in EPoA, replace it with the upstream hash-based construction. If not (expected for PoA), record that no VRF migration is required. * **Ratified decision:** Gen6 adopts upstream Substrate/Polkadot PQC primitives as released rather than forking a parallel implementation. This is the single most important strategic choice in the plan. **Exit criteria:** account migration live on test network then mainnet; authorities signing with ML-DSA; VRF question closed; full cutover rehearsed on a Gen6 test network first. #### Phase 4 — Deprecate classical, bridges, hardening * Enforce the **classical-only sunset** for NCrypt; drop classical signature acceptance for new operations (retaining historical RealSeal verification). * If Gen6 has bridges: implement **post-quantum BEEFY** multi-scheme finality signing (3.6). * Full **third-party cryptographic audit** of the migrated stack. * Publish a **post-quantum readiness statement**; promote GGS-6 to "active." **Exit criteria:** classical primitives removed from new-operation paths; bridges (if any) PQC-verifiable; external audit passed; standard ratified. #### 4.5 Implementation libraries (external, audited — do not hand-roll) * **liboqs** (Open Quantum Safe) — reference ML-KEM / ML-DSA / SLH-DSA / FN-DSA, with C and Rust-accessible FFI bindings. * **Cloudflare CIRCL** — production-grade Go implementations. * **OpenSSL 3.4+** — native ML-KEM and ML-DSA for TLS-adjacent transport. * For a Substrate (Rust) chain, prefer a **Rust PQC implementation with a public audit trail**. The `@scure/sr25519` precedent (Polkadot Treasury-funded, independently audited by Oak Security) is the model to require on the PQC side. **Rule:** every cryptographic library entering Gen6 must have a public audit trail. No unaudited lattice implementation ships to mainnet. *** ### 5. Summary — Algorithm to Component Map | Gen6 component | Current | Post-quantum target | NIST std | Priority | | ------------------------------------ | -------------------------- | ------------------------------------------------------- | ---------------- | ------------- | | NCrypt key exchange | X25519 | **Hybrid X25519 + ML-KEM-768** | FIPS 203 | **P0 (HNDL)** | | NCrypt payload cipher | ChaCha20-Poly1305 | Retained (256-bit, quantum-acceptable) | — | n/a | | NCrypt sender auth | Ed25519 | **ML-DSA (Dilithium)** | FIPS 204 | P1 | | GSX account signatures | sr25519 | **FN-DSA (Falcon)** | FIPS 206 (draft) | P1 | | RealSeal / RealSeal IoT hashing | BLAKE2 / BLAKE3, SHA-256 | Retained (quantum-acceptable) | — | n/a | | RealSeal / RealSeal IoT signing | Ed25519 / sr25519 | **ML-DSA (Dilithium)** | FIPS 204 | P1 | | RealSeal (long-lived/high-assurance) | — | SLH-DSA (SPHINCS+) | FIPS 205 | P2 | | EPoA authority signing | Ed25519 / sr25519 | **ML-DSA (Dilithium)** | FIPS 204 | P3 | | EPoA randomness/VRF (if any) | To confirm in Phase 0 | Hash-based construction only if a vulnerable VRF exists | — | P3 | | Account migration | curve key from hashed seed | FRI-SNARK seed-knowledge proof → Falcon key | — | P3 | | Transport (node-to-node) | X25519-based | Hybrid PQC KEX + PQ-TLS (audited lib) | FIPS 203 | P2 | | Bridges (if any) | To confirm in Phase 0 | Post-quantum BEEFY (multi-scheme) | FIPS 204 | P4 | ### 6. Sources **Standards (primary):** * NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), finalized 13 August 2024. FIPS 206 (FN-DSA / Falcon) in draft. * NSA CNSA 2.0 — 2030 migration deadline for national-security systems; ML-KEM-1024 and ML-DSA-87 specified for NSS. **Substrate / Polkadot-specific (primary for the chain layer):** * Web3 Foundation, "Post-Quantum Cryptography Roadmap for Polkadot and JAM," Polkadot Forum, June 2025 — Dilithium for validator/authority signatures, Falcon for accounts, hybrid KEX for transport, FRI-SNARK account migration, hash-based randomness beacon replacing BABE's VRF, post-quantum BEEFY for bridges. * Polkadot Wiki / Polkadot Developer Docs — current Substrate cryptography (sr25519, Ed25519). **Sizes / benchmarks (secondary, for parameter tradeoffs):** * ML-KEM public keys 800–1568 B, ciphertexts 768–1568 B; ML-DSA signatures 2420–4595 B; SLH-DSA signatures 7856–49856 B; Falcon signatures \~666 B; SLH-DSA (SHA2-128s) \~274 ms/sign on Apple M-series (liboqs) — from NIST-derived and peer-reviewed benchmark literature.