Quantum‑Safe Readiness: A Practical Migration Path
Auspexi • Updated: • Read time: ~10–12 minutes
TL;DR: We already ship air‑gapped packages, dual‑control signing, and evidence bundles with crypto inventories. Our roadmap adds hybrid signatures (ECDSA + ML‑DSA) and ML‑KEM for app‑level key exchange, enforced by policy gates that fail‑closed when a non‑PQC path is detected. All calibration runs in your tenant (zero‑trust), and no raw data leaves by default.
Why quantum‑safe matters now
NIST has finalized post‑quantum standards (ML‑KEM, ML‑DSA, SLH‑DSA, HQC). Major vendors are rolling out quantum‑resilient roadmaps across TLS, signatures, and key exchange. For builders delivering evidence‑bearing AI, crypto agility and migration discipline are as important as model quality.
What AethergenPlatform already ships
- Air‑gapped packaging: offline bundles with SBOM, checksums, and QR‑verified manifests for secure review.
- Dual‑control signing: operational flow where releases require explicit approval (two‑person control) before signing artifacts.
- Evidence bundles: signed acceptance, stability, privacy probes, and manifests with integrity metadata (crypto inventory).
- Zero‑trust calibration: runs in your Databricks; outputs are small JSON artifacts and signed proof. No raw data leaves.
Our PQC migration approach
We treat PQC like any other safety upgrade: inventory —› hybrid —› default —› deprecate legacy.
- Inventory: declare hash/signature algorithms per artifact (manifest.json + crypto_profile.json) and surface them in evidence.
- Hybrid: adopt hybrid signatures (ECDSA + ML‑DSA) and hybrid key exchange (ECDH + ML‑KEM) at the application layer.
- Policy gates: CI and runtime gates fail‑closed when the required PQC profile is not present.
- Default + deprecate: once hybrid is stable, move to PQC‑only for high‑risk packages, keep hybrid for broad compatibility.
What “hybrid” means here
- Signatures: we produce both a classical signature (e.g., ECDSA/Ed25519) and a PQC signature (ML‑DSA). Verifiers accept either or require both by policy.
- Key exchange: for app‑level channels (e.g., evidence delivery), encapsulate a shared secret via ECDH + ML‑KEM and derive session keys.
Operational guardrails
- Fail‑closed: when PQC is required, non‑PQC paths throw, and releases halt until fixed.
- Crypto inventory: evidence explicitly lists algorithms, versions, and policies used for each artifact.
- Air‑gapped verification: verification instructions work offline; no cloud dependency to validate signatures.
Running in your tenant (zero‑trust)
The safest place to calibrate is your environment. We provide notebooks that compute anchors and run acceptance checks inside your Databricks account, then export only signed summaries. This keeps your secrets and data in your control while producing proof that auditors can file.
Roadmap highlights
- Publish crypto_profile.json with every bundle; include hash/signature/KEM details.
- Add optional “require_pqc=true” policy to block releases without hybrid signatures.
- Introduce LibOQS/WASM path for ML‑DSA and ML‑KEM in offline verification tools.
- Document verifier flows: classical‑only, PQC‑only, and hybrid‑required.
Get hands on
We’re happy to run a private pilot to produce PQC‑ready evidence for your environment and policies.