Crypto Agility 2.0 · Beta · Gate β

Swap algorithms without rewriting the app

A central registry of 11 algorithms + policy engine + dynamic negotiation. When an algorithm falls, we rotate on heartbeat, not hotfix.

Honest beta: registry, policy engine, negotiation, migration and audit log are in production. Falcon and SPHINCS+ are reserved (flag implementationAvailable:false) until pqsl-core v3.1/v3.2. FIPS 140-3 module cert is in progress — not a current claim.

View public registry (JSON)Enterprise deprecation calendar →

What is crypto-agility (no buzz)?

Crypto-agility is the ability to swap an application\'s cryptographic algorithm without rewriting code, without forced downtime and without losing encrypted data along the way. Sounds trivial, but most systems have the algorithm hardcoded: the day NIST warns Dilithium2 is broken, every engineer spends a week swapping strings.

PosQuantum\'s architecture turns the algorithm into a database record. Each primitive (KEM, DSA, AEAD, Hash) has a versioned slug. The application never references "kyber768" directly — it asks the server which algorithm to use. When it changes, it changes for everyone.

This is critical for the post-quantum world because we will have multiple migrations: Dilithium → Falcon in some cases, SPHINCS+ as hash-based backup, eventual Dilithium2 to Dilithium3, hybrid → pure PQ once confidence is sufficient. Not an event — a continuous process.

The 11 algorithms in registry

Snapshot of what is cataloged today. Canonical JSON lives at GET /api/crypto/algorithms — no auth required.

Slug	Family	NIST	Status	Pref.	Impl.	Notes
kyber768-x25519-hybrid-v1	hybrid-kem	L3	active			Hybrid KEM (Kyber768 + X25519) — preferred. PQ+classical cascade for defense in depth.
kyber768-v1	kem	L3	active	—		Pure ML-KEM-768 (Kyber) — FIPS 203, no classical fallback.
kyber1024-x25519-hybrid-v1	hybrid-kem	L5	active	—		Level-5 hybrid variant (Kyber1024 + X25519) for ultra-sensitive scenarios.
kyber1024-v1	kem	L5	active	—		Pure ML-KEM-1024 (Kyber) — FIPS 203, level 5.
dilithium3-v1	dsa	L3	active			ML-DSA-65 (Dilithium3) — preferred. FIPS 204 post-quantum digital signatures.
dilithium5-v1	dsa	L5	active	—		ML-DSA-87 (Dilithium5) — level 5, FIPS 204.
falcon512-v1	dsa	L1	active	—	reserved	Falcon-512 — compact signatures. Reserved in registry; implementation in pqsl-core v3.1+.
sphincs-shake-128f-v1	dsa	L1	active	—	reserved	SPHINCS+ SHAKE 128f — hash-based, no lattice reliance. Reserved; implementation in pqsl-core v3.2+.
ed25519-v1	classical-dsa	L1	deprecated	—		Ed25519 — classical signature. Deprecated on 2026-04-01 (no removal date announced).
x25519-v1	classical-kem	L1	active	—		X25519 — classical ECDH. Used only in hybrid mode (never standalone).
aes-256-gcm-v1	aead	L5	active			AES-256-GCM — symmetric AEAD. Quantum-safe (Grover requires 2×key).

How it works — 5 steps

From registry to audit log, nothing hidden.

Registry

Central algorithm catalog in database. Each algo has slug, family, NIST level, status, flags.

Policy

Global + per-customer policy: min NIST level, banned algos, classical accept/reject.

Negotiate

Client sends candidates. Server applies policy and picks a compliant set (kem+dsa+aead).

Migrate

On deprecation, server flags pendingAlgorithmRotation. Agent/client rotates on next heartbeat.

Audit

Every negotiation, policy change, deprecation and rotation is logged in CryptoEvent with origin IP.

6 architectural decisions (and why)

Each decision was debated and documented before code. No marketing — just trade-offs.

Ed25519 enters as deprecated

Not "active" on day one. Honesty: market needs time, but the warning is immediate.

Default rejects pure classical

Customer must explicitly opt-in via allowClassicalFallback. No surprises.

Eager rotation on heartbeat

Server flags pendingAlgorithmRotation; agent/client rotates on next heartbeat. No maintenance window wait.

Negotiation requires API Key

GET /algorithms is public (transparency). POST /negotiate requires customer API key (auditability + rate-limit).

Global policy + per-customer override

Direct MVP: one global policy + optional overrides. Policy hierarchy moves to Gate γ if needed.

Drive Guard rotation separate for now

Drive Guard wrapKey rotation stays in its dedicated flow. Full unification in Gate γ.

What it doesn't do yet — and when it will

This section exists because "crypto-agility" is marketing-abused. Here's what's missing to be honest.

FIPS 140-3 module: in progress

The fipsCompliant:true flag means crates implement FIPS 203/204. Module certification (hw or sw) is targeted Q3 2026. We do not claim "FIPS-certified" before a CMVP cert in hand.

Falcon and SPHINCS+: reserved

Both show in registry with implementationAvailable:false. We only negotiate Falcon or SPHINCS+ signatures after pqsl-core v3.1 and v3.2. They are in registry for the migration pipeline — not for use today.

Negotiation is application-level, not TLS

The /api/crypto/negotiate endpoint is HTTP over classical TLS. KEM/DSA/AEAD negotiation happens in the payload to decide which primitives to use inside the app. Post-quantum TLS handshake is out of scope for this phase.

Rotation is not always zero-downtime

For Drive Guard, wrapKey rotation requires the agent online. If the device is offline, it stays in pendingAlgorithmRotation until next heartbeat. For new PUCE archives, applies automatically.

No HSM in MVP

Customer keys are encrypted in DB (AES-256-GCM with app key). External HSM / KMS (CloudHSM, YubiHSM) is targeted for Gate γ — we'll announce when integrated.

Ed25519 deprecation without removal date

We marked Ed25519 as deprecated on 2026-04-01 to warn the market. We do not announce removedAt because it would be a fictional deadline — removal depends on substitute maturity (Dilithium3 is the default) and customer adoption.

For developers

2 public endpoints. Auth only where audit makes sense.

GET /api/crypto/algorithms

Public registry listing. No auth. Rate-limit 100/min per IP.

$ curl https://posquantum.com/api/crypto/algorithms
{
  "algorithms": [
    {
      "slug": "kyber768-x25519-hybrid-v1",
      "family": "hybrid-kem",
      "nistLevel": 3,
      "status": "active",
      ...
    }
  ]
}

POST /api/crypto/negotiate

Customer API key required. Rate-limit 60/min per customer. Logs to CryptoEvent.

$ curl -X POST .../negotiate \
  -H "Authorization: Bearer pq_live_..." \
  -d '{
    "candidates": {
      "kem": ["kyber768-x25519-hybrid-v1"],
      "dsa": ["dilithium3-v1"],
      "aead": ["aes-256-gcm-v1"]
    }
  }'
→ { "ok": true, "selected": { ... } }

Full auditability

Every module action lands in a structured log (CryptoEvent): each negotiation, each policy change, each scheduled deprecation, each rotation flag. Fields: timestamp, customerId, userId, actorType, eventType, algorithmSlug, metadata (JSON), originIp.

View audit page Admin console (login)

Dedicated deprecation calendar

Enterprise customers get private deprecation calendar 12 months ahead, per-tenant policies and a seat in technical councils on Falcon/SPHINCS+ substitution. Talk to the team.

Talk to the team