Cryptographic Agility PoC

Quantum Threat & Cryptographic Agility

A Cryptographically Relevant Quantum Computer (CRQC) breaks RSA, ECDSA, and ECDH via Shor's algorithm. NIST published three quantum-safe standards in August 2024. Cryptographic agility is the ability to negotiate and rotate algorithms without changing protocols.

Harvest Now, Decrypt Later — Adversaries are recording encrypted traffic today to decrypt once a CRQC exists. Long-lived key material (TLS sessions, identity tokens, stored secrets) is already at risk.

2030–

CRQC estimates begin

NIST FIPS published 2024

RFC 7696

Crypto Agility standard

NIST PQC Standards (August 2024)

Standard	Algorithm	Purpose	Security Level
FIPS 203	ML-KEM (Kyber)	Key encapsulation (replaces ECDH)	L1/L3/L5
FIPS 204	ML-DSA (Dilithium)	Digital signatures (replaces ECDSA)	L2/L3/L5
FIPS 205	SLH-DSA (SPHINCS+)	Hash-based signatures (stateless)	L1/L3/L5

Migration Strategy

Phase 1 — Hybrid (now)

Run classical + PQC in parallel. Both must be broken for the system to be compromised. Used in TLS 1.3 as X25519+ML-KEM-768.

Phase 2 — PQC Only (CRQC era)

Deprecate classical algorithms once CRQC threat is active. Crypto agility ensures rotation happens without protocol changes.

ML-KEM-768 — Key Encapsulation

ML-KEM (NIST FIPS 203) replaces ECDH for key exchange. It is a Key Encapsulation Mechanism: the sender encapsulates a shared secret using the recipient's public key; only the recipient can decapsulate it.

Key Encapsulation Flow

The private key dk never leaves the recipient. Only ek (public) and ct travel on the wire.

Click to generate key pair and run encapsulation...

Size Comparison

Property	ECDH P-256	ML-KEM-768	Overhead
Public key	65 bytes	1,184 bytes	×18
Ciphertext / KEM output	65 bytes	1,088 bytes	×17
Shared secret	32 bytes	32 bytes	×1
Quantum-safe	No	Yes	—

Go stdlib: ML-KEM-768 is in the Go standard library as crypto/mlkem since Go 1.24. This demo uses a real implementation — not a simulation.

ML-DSA-65 — Digital Signatures

ML-DSA (NIST FIPS 204) replaces ECDSA for digital signatures. It is a lattice-based scheme with significantly larger keys and signatures than classical algorithms — but is quantum-safe.

Sign → Verify Flow & Quantum Risk

Private key never leaves the issuer. Verifier only needs the public key (1,952 B). Classical ECDSA private key is recoverable by a CRQC via Shor's algorithm.

Click to generate key pair and sign a token payload...

Size Comparison

Property	ECDSA P-256	Ed25519	ML-DSA-65
Public key	65 bytes	32 bytes	1,952 bytes
Signature	72 bytes (DER)	64 bytes	3,309 bytes
Quantum-safe	No	No	Yes

JWT Identity Token Transition

Today (classical)

{"typ":"agent+jwt","alg":"ES256"}
{"sub":"spiffe://bank.internal/agent-1",
 "iss":"https://idp.bank.internal"}

Post-quantum era

{"typ":"agent+jwt","alg":"ML-DSA-65"}
{"sub":"spiffe://bank.internal/agent-1",
 "iss":"https://idp.bank.internal"}

JOSE alg values for ML-DSA are being standardised in the IETF JOSE WG (draft-ietf-jose-fully-specified-algorithms). The algorithm ID shown is illustrative.

Hybrid Classical + Post-Quantum

During the transition, running both classical and PQC algorithms in parallel provides defense-in-depth: an attacker must break both to compromise the session. This is the approach adopted in TLS 1.3 (X25519+ML-KEM-768).

Click to see X25519+ML-KEM-768 side by side...

Two-Leg Handshake — Both Legs Must Be Broken to Win

Each leg produces an independent shared secret. The session key is KDF(ss₁ ‖ ss₂) — an attacker must break both simultaneously.

Algorithm Negotiation & Rotation

Crypto agility (RFC 7696) means a system can negotiate the strongest mutually-supported algorithm and rotate when threat level changes — without protocol changes.

Algorithm Negotiation

Each peer advertises its supported algorithms. The negotiation picks the strongest common algorithm: post-quantum > hybrid > classical. Try a mix where only classical overlaps — watch the risk flag.

Local peer supports

Remote peer supports

Select peer capabilities and click Negotiate...

Threat Level → Algorithm Rotation

As the quantum threat evolves, the active algorithm set must change — without protocol changes. Each level shows which algorithms are required and why.

Select a threat level to see the rotation policy...

Private AI Inference — Homomorphic Encryption

When you query an AI model, the server sees your raw inputs — your prompts, your data, your query intent. Homomorphic encryption (HE) changes this: the server computes on encrypted inputs and returns an encrypted result. It never sees plaintext at any point.

Why Private Inference Matters

❌ Without HE (today's default)

Client holds: inputs = [5, 3, 8]

↓ sends plaintext

Network: data exposed in transit

↓

Server: sees [5, 3, 8] ⚠ logs your query · fingerprints your data · stores inputs

↓ plaintext result

Server also sees your result: 5.2

Exposure surface: query intent, proprietary data, user behaviour, results — all visible to the model provider, logged, and potentially breachable.

✓ With Homomorphic Encryption

Client holds: inputs = [5, 3, 8]

↓ HE.Encrypt()

Ciphertexts: [X₁, X₂, X₃] — opaque blobs

↓ sends only ciphertexts

Server: sees ??? (ciphertexts only) applies model weights · computes dot product on ciphertexts

↓ encrypted result

Encrypted output: [R] — server never decrypts

↓ HE.Decrypt() — client only

Result: 5.2 (plaintext, client-only)

Server's view: three opaque blobs in, one opaque blob out. Zero knowledge of your data, query intent, or result.

The Homomorphic Property — Why Math Works on Ciphertexts

In additive HE, Dec(Enc(a) + Enc(b)) = a + b without ever decrypting a or b individually.

This means a dot product (the core of every neural network layer) can run entirely on ciphertexts:

result_enc = Σ (Enc(input_i) × weight_i)
result     = Decrypt(result_enc)
           = Σ (input_i × weight_i)

HE scheme families:

BFV / BGV — exact integers · batching · database queries
CKKS — approximate floats · neural network inference · ML
TFHE — boolean circuits · arbitrary programs · slower
HEIR — Google's IR compiler targeting all three

HEIR (Homomorphic Encryption Intermediate Representation) — Google's open-source compiler IR for HE programs, lowering HE operations to hardware-optimised instruction sequences. Not an IETF standard, but the leading open approach to making HE inference practical at inference-server scale.

Simulated HE Inference Demo

Enter input values and weights. The client encrypts inputs; the server computes the weighted sum on ciphertexts.

Inputs (comma-separated integers)

Weights (comma-separated floats)

Enter inputs and weights, then click Run...

HE Scheme Comparison

Scheme	Data Type	Operations	Use Case
BFV / BGV	Integers	+, ×	Statistical queries, exact computation
CKKS	Floating point	+, ×, approx.	Neural network inference, ML
TFHE	Boolean circuits	AND, OR, NOT	Arbitrary programs (slow)
This demo	Integer (fixed-pt)	+, × scalar	Additive homomorphism illustration

Identity & Auth Token Transition

WIMSE workload identity tokens (WIT), agent tokens, and mTLS certificates all use classical algorithms today. The transition to PQC affects every layer — and the threat begins now, not when a CRQC exists.

Harvest Now, Decrypt Later — Why Transition Starts Today

2025 — Today2027–28 — Stored2030+ — CRQC Era

Classical (ECDSA P-256 / ES256)

Agent issues
alg: ES256
JWT

→

Attacker records
📦 encrypted vault
waits for CRQC

→

Shor's algorithm
recovers EC priv key
⚠ Forges tokens!

Post-Quantum (ML-DSA-65 / FIPS 204)

Agent issues
alg: ML-DSA-65
JWT

→

Attacker records
📦 encrypted vault
waits for CRQC

→

Shor's tries lattice
No known attack
✓ Cannot forge

Adversaries are recording today's JWT traffic. Tokens signed with ECDSA can be retroactively broken once a CRQC exists. Tokens signed with ML-DSA-65 are safe even in the CRQC era — lattice problems have no known quantum speedup.

SPIFFE / SVID Migration Roadmap

Add ML-DSA-65 signing key to SPIRE server
Both EC and ML-DSA keys active. SPIRE issues classical SVIDs only.

Issue hybrid SVIDs (ECDSA + ML-DSA-65)
Both certs included. Workloads negotiate the strongest mutual algorithm on connect.

Rotate TLS key exchange to X25519+ML-KEM-768
Configure TLS 1.3 hybrid group. All new sessions use both legs.

Decommission classical signing key (after SVID TTL expires)
Wait for all outstanding SVIDs to expire. Rotate Root CA to ML-DSA-87.

✓

Full PQC posture — CRQC-ready
All identity tokens, key exchanges, and certs use quantum-safe algorithms.

JWT / Agent Token (today)

Header:
{
  "typ": "agent+jwt",
  "alg": "ES256",     ← ECDSA P-256
  "kid": "key-2026-01"
}
Payload:
{
  "sub": "spiffe://mesh.internal/workload",
  "cnf": { "jkt": "<EC P-256 thumbprint>" }
}

JWT / Agent Token (PQC era)

Header:
{
  "typ": "agent+jwt",
  "alg": "ML-DSA-65",  ← FIPS 204
  "kid": "pq-key-2027-01"
}
Payload:
{
  "sub": "spiffe://mesh.internal/workload",
  "cnf": { "jkt": "<ML-KEM-768 thumbprint>" }
}

mTLS Certificate Migration

Layer	Today	Transition (hybrid)	PQC era
Root CA signing	ECDSA P-384	ECDSA + ML-DSA-87	ML-DSA-87
Leaf cert signing	ECDSA P-256	ECDSA + ML-DSA-65	ML-DSA-65
TLS key exchange	ECDH P-256	X25519+ML-KEM-768	ML-KEM-768
SPIFFE SVID key	EC P-256	EC + ML-KEM-768	ML-KEM-768

Crypto agility in SPIRE: SPIRE Server signing key must be rotated to ML-DSA before SVID TTL expires. Plan key rotation windows carefully — SVID renewals fail if the signing algorithm is not supported by the SPIRE agent version.

Standards Tracker

Post-quantum cryptography standards relevant to this PoC, tracked across NIST and IETF.

Standard	Body	Status	Purpose	Impl.
NIST FIPS 203	NIST	Published	ML-KEM — key encapsulation	`pkg/pqc/mlkem.go`
NIST FIPS 204	NIST	Published	ML-DSA — digital signatures	`pkg/pqc/mldsa.go`
NIST FIPS 205	NIST	Published	SLH-DSA — hash-based signatures	Registry only
draft-ietf-pquip-pqc-engineers	IETF PQUIP	Active	PQC engineering guide	Threat taxonomy
draft-ietf-tls-hybrid-design	IETF TLS	Active	Hybrid KEM in TLS 1.3	hybridKEMDemo
draft-ietf-jose-fully-specified-algorithms	IETF JOSE	Active	PQC JOSE alg values	Identity tab
HEIR (Google)	Google OSS	Active	HE compiler IR	HE inference tab