Why Post-Quantum Migration Needs Upstream Memory & Input Safety Checks (ciphermap preflight & --with-immunity)
Most post-quantum migration guides focus exclusively on algorithm selection: swapping X25519 or RSA key transport for hybrid ML-KEM-768 (NIST FIPS 203) and transitioning detached signatures toward composite Ed25519 + ML-DSA-65 (NIST FIPS 204). Yet in production services, the hardest failures during PQC rollouts often happen upstream of the cryptographic primitive—inside HTTP body readers, envelope deserializers, and bundle extractors.
The Wire-Size Multiplier: Classical vs. Post-Quantum Artifacts
Lattice-based cryptography trades compact elliptic-curve scalars for structured module lattices with substantially larger wire representations:
| Operation / Standard | Classical Baseline | Post-Quantum / Hybrid Target | Payload Delta |
|---|---|---|---|
| Key Establishment (FIPS 203) | X25519: 32 B pub / 32 Beph | ML-KEM-768: 1,184 B ek / 1,088 B ct | ~35x larger exchange |
| Digital Signatures (FIPS 204) | Ed25519: 32 B pub / 64 B sig | ML-DSA-65: 1,952 B pub / 3,309 B sig | ~51x larger signature |
| Composite Provenance Chain | Single classical cert + .sig | Ed25519 + ML-DSA-65 (.pqc.sig) | Multi-KB header / bundle |
When developers encounter 4 KB–16 KB header or buffer truncations during PQC testing, a common anti-pattern is removing size limits altogether—replacing bounded readers with bare io.ReadAll(r), unbounded JSON/PEM allocations, or unjailed archive unpackers before cryptographic verification runs. Because ML-DSA-65 verification must buffer the message or digest input before rejecting an invalid signature, an uncapped pre-authentication reader turns into an asymmetric memory-exhaustion sink.
Single-Pass Readiness & Safety Previews (--with-immunity)
Instead of running separate, uncoordinated cryptographic and AppSec passes months apart, CipherMap lets engineering teams inspect both surfaces in one deterministic local workflow:
# Step 1: Verify workspace cleanliness and host compiler/test prerequisites (Free, 0 egress) ciphermap preflight . # Step 2: Discover PQC debt (Free) + supported 12-language structural sinks locally (Tier B Fleet, 0 egress) ciphermap scan . --offline --no-telemetry ciphermap immunity scan . --offline --no-telemetry # Step 3: Preview supported PQC + upstream safety candidates and decline reasons (dry-run preview) ciphermap fix . --with-immunity --dry-run
On Enterprise Fleet (Tier B) deployments with explicit --allow-verify-exec consent, supported ciphermap fix --with-immunity and ciphermap immunity extinguish recipes execute inside network-denied OS sandboxes across four gates: (1) structural eligibility and protocol-boundary checks, (2) lazy T0/T1 baseline-and-candidate compilation/testing, (3) post-patch differential self-scan to confirm zero new rule matches, and (4) atomic diff retention or rollback.
Stopping AI Regression Drift with ciphermap mcp, .cursor/rules & CLAUDE.md
Extinguishing legacy SHA-1 calls, pre-FIPS kyber768 imports, or uncapped stream reads only holds if tomorrow's AI-assisted pull request does not re-introduce them. Generic coding agents are heavily weighted toward historical GitHub patterns where RSA-2048, MD5/SHA-1 helpers, and bare ReadAll calls dominate.
Enterprise Fleet closes that loop locally without sending proprietary code to external scanning clouds: committed .cursor/rules and CLAUDE.md policy ratchets instruct Cursor and Claude Code to query ciphermap mcp over local stdio before finalizing edits, while ci-review enforces the same deterministic ruleset on pull requests.
As with all CipherMap remediation workflows, automated rewrites apply strictly to supported recipes; complex protocol negotiations, custom state machines, and ambiguous data flows are declined with explicit rationale so security architects stay in control.