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:
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
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
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):
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:
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.
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.
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:
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-quantumAES-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:
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.
On-chain collision resistance is capped at ~128-bit. The live
dataRegistrypallet stores a fixed 32-byteH256, 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.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.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:
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 — working experimental PQC prototype (notarize, verify, SLH-DSA signing, ML-KEM encryption)
Last updated
Was this helpful?