> 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/solutions/gen6-msg/nc-post-quantum-cryptography.md). # NC Post-Quantum Cryptography ### Why NCrypt Is High Priority in the Entire Gen6 Stack Across all of Gen6, NCrypt is the **only** component where the quantum threat is active today rather than pending. The reason is an asymmetry between confidentiality and authentication: | | Encryption (NCrypt key exchange) | Signatures (accounts, RealSeal, consensus) | | ---------------- | ------------------------------------- | ------------------------------------------ | | Attack | Record ciphertext now, decrypt later | Forge a signature | | When it pays off | Any time in the future | Only at the moment it is used | | Exposure today | **Active** | None | | Deadline | Already passed for long-lived secrets | Before quantum computers exist | An adversary can capture NCrypt traffic **today**, store it, and decrypt it years from now once a sufficiently capable quantum computer exists. This is **Harvest Now, Decrypt Later** (HNDL), and it means any message whose confidentiality must outlast the arrival of quantum computing is **already at risk** — regardless of when that arrival actually happens. A forged signature has no equivalent problem. Forging a validator signature or an account signature in 2035 is worthless, because the block was finalised and the transaction settled years earlier. As the Web3 Foundation researchers put it: for authentication, "you just need to be far enough ahead to rotate the key." **Consequence:** NCrypt key exchange is Phase 1 of the GGS-6 migration, ahead of every signature-related workstream. *** ### Current Cryptographic Layer | Function | Primitive | Quantum status | | --------------------- | -------------------------------- | ------------------------------ | | Key exchange | X25519 (Curve25519 ECDH) | **Broken by Shor's algorithm** | | Sender authentication | Ed25519 (EdDSA) | **Broken by Shor's algorithm** | | Payload encryption | ChaCha20-Poly1305 (256-bit AEAD) | Quantum-acceptable | The split is clean and worth stating precisely: **the public-key components are the entire problem.** ChaCha20-Poly1305 is not a concern — Grover's algorithm halves its effective security, leaving roughly 128-bit post-quantum strength at a 256-bit key, which remains strong. It is retained without modification. *** ### Target Cryptographic Layer | Function | Current | Post-quantum target | Standard | | --------------------- | ----------------- | ------------------------------- | -------- | | Key exchange | X25519 | **Hybrid: X25519 + ML-KEM-768** | FIPS 203 | | Sender authentication | Ed25519 | **ML-DSA (Dilithium)** | FIPS 204 | | Payload encryption | ChaCha20-Poly1305 | **Unchanged** | — | **ML-KEM-768** is the baseline parameter set (NIST Category 3, roughly AES-192-equivalent). ML-KEM-1024 remains available for high-assurance deployments. *** ### Why Hybrid, and Not Pure Post-Quantum NCrypt does **not** replace X25519. It runs X25519 and ML-KEM-768 **in parallel**, combining both shared secrets through a KDF so that the session remains secure if **either** primitive holds. The rationale is conservative and deliberate: * **ML-KEM is new.** It has received far less side-channel cryptanalysis than X25519, which has been under sustained attack for over a decade. * **A hybrid fails safely.** A flaw in the lattice scheme leaves X25519 protecting the session. A quantum computer defeating X25519 leaves ML-KEM protecting it. Both must break for the session to break. * **This is the field standard, not a Gen6 invention.** OpenSSH has shipped `mlkem768x25519-sha256` — the identical construction — as its **default** key exchange since version 10.0 (April 2025), and OpenSSH 10.1 warns on any connection not using a post-quantum KEX. Chrome and major TLS stacks deploy the same pairing. Pure post-quantum key exchange is deferred until ML-KEM side-channel analysis matures. Hybrid only, for now. *** ### Practical Impact: Sizes and Performance Post-quantum primitives are substantially larger than the elliptic-curve primitives they replace. For a messaging application this is a real engineering consideration, not a footnote. **Public keys (per identity, published on the Gen6 chain):** | | Current | Post-quantum | Increase | | ----------------------- | ------------- | ------------------------------------- | --------- | | Key-exchange public key | X25519: 32 B | ML-KEM-768: 1,184 B | \~37x | | Signing public key | Ed25519: 32 B | ML-DSA-65: 1,952 B | \~61x | | **Total per identity** | **64 B** | **\~3,168 B** (hybrid retains X25519) | **\~50x** | **Per-message overhead:** | | Current | Post-quantum | Increase | | ---------------- | ------------- | ------------------- | -------- | | KEM ciphertext | X25519: 32 B | ML-KEM-768: 1,088 B | \~34x | | Sender signature | Ed25519: 64 B | ML-DSA-65: 3,309 B | \~52x | **What this means in practice:** * **On-chain key storage grows materially.** NCrypt public keys are published on the Gen6 blockchain so that other users can initiate encrypted contact. A \~50x increase in per-identity key size across a growing user base is a storage and bandwidth planning item that must be sized before rollout, not discovered during it. * **Per-message overhead is the more visible cost.** A short text message currently carries under 100 bytes of cryptographic overhead. Post-migration it carries roughly 4.4 KB. For long-form messages this is negligible; for high-frequency short messages it is not. * **Payload encryption cost is unchanged.** ChaCha20-Poly1305 performance is unaffected, so the cost is in key establishment and signing, not in encrypting message bodies. These figures are the reason ML-KEM-768 (rather than 1024) and ML-DSA-65 are the baseline: they meet Category 3 security at the smallest practical size. *** ### Working Prototype: pqc.gen6.life A functioning post-quantum toolkit already exists and runs against the live Gen6 chain: [**pqc.gen6.life**](https://pqc.gen6.life). It is explicitly marked **in development and experimental**, and it is broader than NCrypt — it is a RealSeal Notary PQC prototype with an encryption module. But it matters here because **the ML-KEM encryption path described in this page is already implemented and working end to end.** #### What runs today The prototype is **entirely client-side**. Files and messages never leave the browser, and post-quantum keys are generated in-browser, held in memory only, never uploaded or auto-saved. | Function | What it does | Algorithms | | ------------ | ----------------------------------------------------------------------------------------------------- | --------------------------------------- | | **Notarize** | Hash a file locally, seal the digest on-chain | SHAKE256/256 → `dataRegistry.storeData` | | **Verify** | Recompute the hash, compare, optionally confirm the on-chain record in its block | SHAKE256 | | **Sign** | Generate a PQC keypair in-browser, sign a file's digest, anchor the signature hash on-chain | SLH-DSA (FIPS 205) | | **Encrypt** | Encapsulate a shared secret to a recipient's public key, encrypt the message, full decrypt round-trip | ML-KEM (FIPS 203) + AES-256-GCM | **Encryption module detail — directly relevant to NCrypt:** * ML-KEM parameter sets selectable: **ML-KEM-512, ML-KEM-768 (recommended), ML-KEM-1024** * Optional **encrypt-then-sign** — the ciphertext can be signed with SLH-DSA, giving authenticated encryption with a post-quantum signature * Exportable encrypted bundle, with decryption of bundles produced elsewhere * Verified round-trip: encrypt → export → import → decrypt This is a working demonstration that ML-KEM key establishment plus AEAD payload encryption functions correctly in a Gen6 context. The NCrypt Phase 1 work is therefore an integration and hardening task on a proven path, not a research question. #### Chain integration The prototype connects to the live node (`wss://gen6.app:443/node`) and submits real extrinsics through the existing `dataRegistry` pallet: ``` dataRegistry.storeData(project_id: u32, hash: H256) ``` Signing is delegated to the user's wallet extension — the page never sees the seed or account private key. #### Implementation * **SLH-DSA and ML-KEM:** `@noble/post-quantum` * **AES-256-GCM:** WebCrypto * **Key custody:** PQC keys are separate from the on-chain account key. Held in memory, exportable by the user. If lost they are unrecoverable; if leaked, another party can sign or decrypt as that identity. #### Known limitations — stated by the prototype itself These are real constraints, documented on the page, and each one is informative for the production migration: 1. **Not verifiable by standard Gen6 RealSeal apps.** The prototype hashes with **SHAKE256**, while production RealSeal uses BLAKE2b-256. On-chain records produced here are only verifiable through the prototype's own Verify tab. 2. **On-chain collision resistance is capped at \~128-bit.** The live `dataRegistry` pallet stores a fixed 32-byte `H256`, so the on-chain digest is SHAKE256/256. The full 512-bit SHAKE256 fingerprint is retained off-chain in the receipt. **Raising on-chain collision resistance requires the pallet to accept more than 32 bytes** — a runtime change, not a client-side one. 3. **Signatures are anchored, not stored.** SLH-DSA signatures are KB-scale, so the chain holds `storeData(projectId, SHAKE256(signature))` while the full signature stays in the downloadable receipt. This is the practical consequence of the size figures in the table above. 4. **The account signature remains classical.** Transactions are still signed sr25519/ed25519 by the wallet extension. The prototype demonstrates post-quantum content signing and encryption; it does not make the chain's own account layer post-quantum. That is GGS-6 Phase 2–3 work. #### Divergences from GGS-6 — to reconcile before production The prototype makes several algorithm choices that differ from this standard. None are errors in a prototype, but each needs an explicit decision before production: | Prototype | GGS-6 specifies | Note | | ----------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **SLH-DSA** as the signature | **ML-DSA (Dilithium)** as default; SLH-DSA reserved for long-lived/high-assurance | SLH-DSA signatures are 7.8–17 KB at the prototype's parameter sets vs \~3.3 KB for ML-DSA-65. The SHAKE pairing with SHAKE256 hashing is coherent, but the size cost is significant for routine signing. | | **SHAKE256** hashing | **BLAKE2/BLAKE3** (production RealSeal) | Deliberate in the prototype, but it is precisely why output is not cross-verifiable with production apps. | | **AES-256-GCM** payload | **ChaCha20-Poly1305** (NCrypt) | Reasonable for a browser context — AES-GCM is natively available in WebCrypto. NCrypt production retains ChaCha20-Poly1305. | | **Pure ML-KEM** encapsulation | **Hybrid X25519 + ML-KEM-768** | The prototype demonstrates the PQC half. Production NCrypt requires the hybrid construction, so classical and post-quantum secrets are KDF-combined. | The single most consequential of these is the **hybrid requirement**: a prototype may reasonably demonstrate ML-KEM alone, but production NCrypt must run X25519 in parallel so a flaw in either primitive does not break confidentiality. *** ### Migration Plan NCrypt migration is **Phase 1** of GGS-6, and is gated only by Phase 0 (crypto-agility refactor and inventory). #### Step 1 — Crypto-agility in the NCrypt layer Ensure key exchange, signing, and AEAD are reached through an abstraction with explicit algorithm identifiers, rather than X25519/Ed25519 being hard-coded at call sites. Nothing else can proceed cleanly until this exists. #### Step 2 — Wire format versioning Version the NCrypt message format so that the negotiated suite is **explicit and auditable** in every message. A verifier must be able to tell, without ambiguity, whether a given message was protected by hybrid or classical key exchange. #### Step 3 — Hybrid key exchange Implement X25519 + ML-KEM-768 in parallel with KDF combination. Use an audited library (liboqs, or a Rust PQC implementation with a public audit trail) — no hand-rolled lattice code reaches mainnet. #### Step 4 — Key generation at wallet creation NCrypt keys are generated at wallet creation, in seed-words format alongside the wallet keys. This flow must be extended to generate the post-quantum keypair at the same moment, so that a newly created identity is PQC-capable from its first message rather than requiring a later migration step. Existing identities require a key-rotation path: generate and publish a post-quantum NCrypt public key bound to the existing identity, then negotiate hybrid with any peer that supports it. #### Step 5 — Sender authentication migration Migrate NCrypt sender signatures from Ed25519 to ML-DSA. Lower urgency than key exchange (no HNDL exposure), but it aligns NCrypt with the account and RealSeal signature migration in GGS-6 Phase 2. #### Step 6 — Negotiation, fallback, and sunset Ship backward-compatible negotiation: hybrid where both peers support it, classical fallback only where a peer has not upgraded. Publish a **classical-only sunset date** in advance, and enforce it in Phase 4. Downgrade resistance must be explicitly tested — an attacker must not be able to force a classical-only session between two hybrid-capable peers. *** ### Backward Compatibility * **Existing messages remain readable.** Migration does not invalidate previously encrypted content for their intended recipients. * **Mixed-capability periods are expected.** Not every client updates simultaneously. Negotiation handles this, with the suite recorded explicitly per message. * **Classical fallback is temporary and dated.** It exists to avoid breaking communication during rollout, not as a permanent option. The sunset date is announced ahead of enforcement. *** ### What Does Not Change * **ChaCha20-Poly1305** remains the payload cipher. No migration required. * **Keys remain user-held.** Post-quantum migration does not alter NCrypt's custody model — private keys are generated on the user's device and are never held by Gen6. * **End-to-end property is preserved.** Hybrid key exchange changes how the session key is established, not who can read the message. No server sees plaintext before or after migration. *** ### Related Pages * **GGS-6: Post-Quantum Infrastructure** — the parent standard, covering the full Gen6 stack * **NCrypt** — product overview and encryption layer * **Integrity** — the RealSeal integrity guarantee and its own signature migration path * [**pqc.gen6.life**](https://pqc.gen6.life) — working experimental PQC prototype (notarize, verify, SLH-DSA signing, ML-KEM encryption)