Post-Quantum Cryptography — Implementation & Timeline
How Writ implements hybrid post-quantum key exchange, ML-DSA code signing, SLH-DSA fleet roots, and the crypto-agility wrapper that makes CNSA 2.0 a configuration change rather than a rewrite.
Cryptography reviewers · Security architects · Accreditors
This paper documents the post-quantum cryptography posture of the Writ platform as of April 2026. It covers the hybrid edge TLS implementation (X25519 + ML-KEM-768), the artifact-signing stack (cosign v3 with ML-DSA-65), the offline fleet root signed with SLH-DSA, the crypto-agility wrapper, and the CBOM evidence that makes the posture auditable. It also maps Writ's current state and roadmap to the CNSA 2.0 and NSM-10 compliance schedules.
1. Why this paper exists
Between 2027 and 2035, every U.S. government system will be required to transition to post-quantum cryptography under the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) and National Security Memorandum 10 (NSM-10). Commercial vendor post-quantum roadmaps as of Q2 2026 are overwhelmingly targeted at 2027–2029. Systems awarded today that are not architected for crypto-agility face a costly retrofit — the historical multiplier on retrofit cost versus day-one design is approximately 10×.
Writ is designed to make that retrofit a configuration change, not a software rewrite. This paper documents exactly how.
2. Threat model
We assume two distinct adversary classes:
Store-now-decrypt-later. A capable adversary records encrypted traffic today with the intent to decrypt it once a cryptographically-relevant quantum computer is available. The economic value of stored traffic determines how far back this problem reaches. For government data with 25–50 year classification half-lives, this problem is live today — decryption in 2040 is still a compromise of 2026 secrets.
Signature forgery at quantum scale. Once a capable adversary has a quantum computer, classical signature schemes (ECDSA, EdDSA, RSA-PSS) become forgeable. Every long-lived signing key is a liability. Every verifier that trusts only classical signatures is a future compromise.
Our defensive posture addresses both.
3. Algorithm selection
Writ deploys only NIST FIPS 203 / 204 / 205 algorithms at stable parameters:
- ML-KEM-768 (FIPS 203, formerly Kyber-768) for key encapsulation. Category 3 security level.
- ML-DSA-65 (FIPS 204, formerly Dilithium-65) for fast signatures. Category 3 security level.
- SLH-DSA-SHA2-256s (FIPS 205, formerly SPHINCS+) for long-lived, offline-root signatures. Category 5 security level. Hash-based — no elliptic-curve or lattice assumptions.
We do not deploy Falcon (ML-DSA’s sibling) in production. Constant-time implementations of Falcon are notoriously difficult to get right, and the community review has preferred ML-DSA’s simpler implementation profile for platform code. We re-evaluate annually.
We do not deploy stateful hash-based signature schemes (XMSS, LMS) outside of the offline signing ceremony toolchain, because they require key-state tracking that platform code should not be responsible for.
4. Edge TLS — dcrypto v2-hybrid-edge
North-south ingress at every enclave terminates at an Envoy edge proxy configured with the oqs-provider OpenSSL engine. The default cipher suite is hybrid X25519 + ML-KEM-768 for key exchange (RFC draft draft-ietf-tls-hybrid-design). Signature authentication on the server side is the existing classical X.509 certificate chain; we add hybrid PQC signature chains in a transitional phase in 2026–2027.
4.1 Fallback behavior
A client that does not advertise the hybrid group ID falls back to X25519-only. This is a conscious transitional choice: as of April 2026 the vast majority of government browsers and automation tools do not yet advertise hybrid groups. We monitor the fallback rate per enclave and publish it in the admin dashboard. The goal is to drive the fallback rate below 1% before removing classical fallback, currently targeted for Q3 2027.
4.2 Packet size considerations
ML-KEM-768 public keys are 1,184 bytes; ciphertexts are 1,088 bytes. A hybrid ClientHello is approximately 2 KB larger than an X25519-only one, which exceeds the 1,500-byte IPv4 MTU and the 1,280-byte IPv6 minimum MTU. TCP TLS is not affected (it segments at the TCP layer). QUIC is affected — our QUIC ingress reserves extra PMTU budget for the hybrid exchange.
5. Internal mesh — roadmap
As of April 2026, internal service-to-service mTLS runs on Istio 1.24 in ambient mode with classical X25519. A dcrypto v3-hybrid-fips suite is in validation; the target default switch is Q3 2027 once Istio’s upstream mesh supports a FIPS 140-3 validated PQC module.
Until the default switch, customers with elevated threat models can opt in to internal-mesh hybrid PQC today via a Helm values override. We track opt-in telemetry and have observed roughly a 7% internal latency penalty — acceptable for most workloads but worth measuring against your SLOs.
6. Artifact signing — cosign v3 + ML-DSA-65
Every artifact produced by the Writ release pipeline is signed with an ML-DSA-65 key:
- Container images
- Helm chart archives
- SBOMs (CycloneDX 1.6)
- CBOMs (CycloneDX 1.6 crypto profile)
- OSCAL evidence bundles
- Audit log segments (hourly rollup)
- Release notes
Signatures are logged to a Rekor transparency log. Verifiers fetch the signature, the Rekor entry, and the certificate chain. cosign v3 supports ML-DSA-65 natively; we run the upstream cosign binary with no fork.
Audit log segments are signed in a rolling fashion — every hourly segment’s signature incorporates the previous segment’s signature hash, producing a tamper-evident chain.
7. Fleet root — SLH-DSA-SHA2-256s, offline
The fleet root is the single key that signs regional roots, which sign enclave root bundles, which sign service identities. The fleet root lives on an offline HSM, never network-connected, used only in quorum-approved signing ceremonies on a scheduled rotation.
We selected SLH-DSA over ML-DSA for the fleet root because:
- Hash-based, no lattice assumptions. If ML-KEM or ML-DSA are ever broken cryptanalytically, the fleet root is still sound.
- Very long keys and signatures, but low usage. SLH-DSA signatures are 29 KB; the fleet root signs a few dozen times per year. The bandwidth cost is negligible; the assurance is high.
- Stateless. Unlike XMSS or LMS, SLH-DSA does not require signer-state tracking — a critical simplification for an offline ceremony workflow.
8. Crypto-agility wrapper
Every Writ service imports a shared dcrypto library rather than calling a specific cipher suite directly. The library reads a GitOps-managed ConfigMap that names the current suite (v1-classical, v2-hybrid-edge, v3-hybrid-fips) and routes through to the appropriate underlying implementation.
Consequences:
- Adding a new suite is a library release plus a ConfigMap change. No service code changes.
- Rolling a suite change is a standard ConfigMap propagation; running pods pick up the new suite on next handshake (or on restart for long-lived connections).
- A/B testing a new suite in a single enclave is a Kustomize overlay; no new code paths.
- The CBOM emitted per release reflects the wrapper’s current default suite and the per-service overrides, if any.
9. CBOM (Crypto Bill of Materials)
Each release publishes a CycloneDX 1.6 CBOM under its crypto profile. For every service, the CBOM declares:
- Which cryptographic primitives the service uses (key agreement, signatures, symmetric ciphers, hash functions, MACs, KDFs)
- Which implementations provide them (e.g.,
oqs-provider 0.6.0,BoringSSL 9a8b...,openssl 3.2.1) - Which algorithms are deployed (e.g.,
ML-KEM-768,X25519,AES-256-GCM,SHA-256) - Whether the algorithm is classical, hybrid, or post-quantum
- The validation status of the implementation (FIPS 140-3, CAVP, NIST test vectors passed, none)
Accreditors consume the CBOM in review. Programs that must demonstrate CNSA 2.0 alignment for their award use the CBOM as their evidence of posture.
10. Compliance timeline
CNSA 2.0 schedule
| Date | CNSA 2.0 requirement | Writ state |
|---|---|---|
| 2022–2025 | Code-signing infrastructure must support PQC | Done. cosign v3 + ML-DSA-65 in production. |
| 2027 | Networking gear must support PQC | Hybrid edge TLS in production since 2026. Internal mesh default 2027 Q3. |
| 2030 | General-purpose systems must support PQC | Crypto-agility wrapper is complete. Customer-visible swap is a ConfigMap edit. |
| 2033 | PQC-only (classical removed) | Classical fallback removed. PQC-only ciphersuites enforced. |
NSM-10 deadline
NSM-10 sets 2035 as the full PQC national-mandate. Platforms architected for agility today will be the mature option; platforms retrofitting in the 2030–2033 window will be in scramble mode.
11. What to look for in vendor due diligence
A useful six-question screen for any AI backend under evaluation for a 2026 award:
- What post-quantum algorithms are deployed in production today, in which components?
- Are they deployed in hybrid mode with classical fallback, or PQC-only? What is the fallback-rate telemetry?
- Who signs release artifacts, with what algorithm, and what transparency log receives the signatures?
- Is there a fleet root? Where does it live? What algorithm signs it?
- Is there a Crypto Bill of Materials published per release? Can I read one?
- If NIST issues an emergency algorithm deprecation, what is the customer’s upgrade sequence — is it a software patch or a config change?
Writ answers all six today. Most vendors answer none today.
12. References
- NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
- NSA CSS CNSA 2.0 Cybersecurity Advisory (September 2022, updated November 2024)
- White House NSM-10 (2022)
- IETF
draft-ietf-tls-hybrid-design— Hybrid key exchange in TLS 1.3 - CycloneDX 1.6 Crypto Profile specification
- Writ Platform Architecture Reference — see WP-001