Cryptography / Advanced / 14 min

Post-Quantum Cryptography (ML-DSA, SLH-DSA)

Quantum-safe signatures for verifiable credentials—future-proof cryptography before quantum computers break RSA and ECC

The Problem: Quantum Computers Will Break Today’s Cryptography

Current cryptography (RSA, ECDSA, Ed25519) relies on hard math problems:

RSA: Factoring large numbers (2048-bit → ~617 decimal digits)
ECDSA: Discrete logarithm on elliptic curves
Ed25519: Variant of ECDSA (Curve25519)

These are secure today because classical computers would take billions of years to solve them.

But quantum computers change the game:

Shor’s Algorithm (1994): Quantum algorithm that factors large numbers and solves discrete logarithm in polynomial time
Practical quantum computer (10,000+ logical qubits): Breaks RSA-2048, ECDSA-256, Ed25519 in hours to days

Timeline:

✅ 2019: Google’s Sycamore (53 qubits) demonstrates “quantum supremacy” (specific task faster than classical)
✅ 2023: IBM Condor (1,121 qubits)—but physical qubits, not fault-tolerant logical qubits
⏳ 2030-2035 (estimate): Cryptographically relevant quantum computer (CRQC)—10,000+ logical qubits, breaks RSA/ECC

The threat is real:

“Store now, decrypt later” attacks: Adversaries record encrypted credentials today, decrypt when quantum computers arrive
Long-lived credentials: Issued in 2026, valid until 2036—quantum computer breaks them mid-lifetime
Identity infrastructure: DIDs, verifiable credentials, trust registries—all rely on RSA/ECDSA signatures

Post-Quantum Cryptography (PQC) solves this: cryptographic algorithms resistant to quantum attacks, standardized by NIST (National Institute of Standards and Technology).

What Is Post-Quantum Cryptography?

Post-quantum cryptography (PQC) refers to cryptographic algorithms that remain secure even if an attacker has a quantum computer.

Key insight: PQC algorithms rely on math problems that are hard for both classical and quantum computers.

NIST PQC Standardization (2016-2024)

Timeline:

✅ 2016: NIST announces PQC standardization process
✅ 2022: NIST selects finalists (4 algorithms)
✅ 2024: NIST publishes FIPS 203, 204, 205 (official standards)

Selected algorithms:

ML-KEM (FIPS 203) — Key Encapsulation Mechanism (encryption)
- Based on: CRYSTALS-Kyber
- Use case: Encrypt data (like TLS handshake)
ML-DSA (FIPS 204) — Digital Signature Algorithm
- Based on: CRYSTALS-Dilithium
- Use case: Sign verifiable credentials, DIDs, certificates
SLH-DSA (FIPS 205) — Stateless Hash-Based Signature
- Based on: SPHINCS+
- Use case: Sign verifiable credentials, DIDs (backup to ML-DSA)

For verifiable credentials, we care about signatures (ML-DSA, SLH-DSA), not encryption (ML-KEM).

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

What Is ML-DSA?

ML-DSA (formerly CRYSTALS-Dilithium) is a lattice-based signature scheme, standardized as NIST FIPS 204.

Security basis:

Lattice problem: “Shortest Vector Problem” (SVP) and “Learning With Errors” (LWE)
Hard for quantum computers: No known efficient quantum algorithm (unlike Shor’s for RSA/ECC)
Hard for classical computers: Exponential time complexity

Properties:

✅ Quantum-safe: Resists Shor’s algorithm
✅ Fast signing: ~1ms (comparable to ECDSA)
✅ Fast verification: ~0.5ms
✅ Deterministic: Same message + key → same signature (reproducible)
⚠ Large signatures: ~2.4 KB (vs. 64 bytes for Ed25519)
⚠ Large public keys: ~1.3 KB (vs. 32 bytes for Ed25519)

ML-DSA Parameter Sets

NIST defines 3 security levels:

Parameter Set	Security Level	Signature Size	Public Key Size	Comparable to
ML-DSA-44	Level 2	~2,420 bytes	~1,312 bytes	AES-128 / RSA-2048
ML-DSA-65	Level 3	~3,293 bytes	~1,952 bytes	AES-192 / RSA-3072
ML-DSA-87	Level 5	~4,595 bytes	~2,592 bytes	AES-256 / RSA-4096

Recommendation: ML-DSA-65 (Level 3) balances security + size for most use cases.

ML-DSA Example: Signing a Verifiable Credential

Step 1: Key generation

# Generate ML-DSA-65 key pair
(public_key, private_key) = ml_dsa_65_keygen()

# Public key: 1,952 bytes (vs. Ed25519: 32 bytes)
# Private key: 4,032 bytes (vs. Ed25519: 32 bytes)

Step 2: Sign credential

credential = {
  "type": "VerifiableCredential",
  "issuer": "did:webvh:company-x",
  "credentialSubject": { "name": "Alice", "role": "Engineer" },
  "issuanceDate": "2026-07-22T00:00:00Z"
}

# Serialize credential (JSON canonicalization)
message = canonicalize_json(credential)

# Sign with ML-DSA-65
signature = ml_dsa_65_sign(private_key, message)

# Signature: 3,293 bytes (vs. Ed25519: 64 bytes)

Step 3: Verify signature

# Verifier receives: credential + signature + issuer's public key
is_valid = ml_dsa_65_verify(public_key, message, signature)

# Result: True (signature valid) or False (invalid/tampered)

Quantum safety: If attacker has quantum computer, cannot forge signature (lattice problem remains hard).

SLH-DSA (Stateless Hash-Based Signature Algorithm)

What Is SLH-DSA?

SLH-DSA (formerly SPHINCS+) is a hash-based signature scheme, standardized as NIST FIPS 205.

Security basis:

Hash functions: Uses SHA-256 or SHAKE256 (standard cryptographic hashes)
No structured problem: Doesn’t rely on lattices, codes, or algebraic structures
Conservative security: If hash functions are secure, SLH-DSA is secure

Properties:

✅ Quantum-safe: No quantum attack on hash functions (Grover’s algorithm only provides quadratic speedup → still secure with larger hashes)
✅ No secret state: Stateless (unlike original hash-based schemes like XMSS, which require state tracking)
✅ Conservative: Minimal assumptions (just hash security)
⚠ Slow signing: ~50-200ms (vs. ~1ms for ML-DSA)
⚠ Very large signatures: ~7-50 KB (vs. ~2.4 KB for ML-DSA)

SLH-DSA Parameter Sets

NIST defines multiple parameter sets (size vs. speed trade-off):

Parameter Set	Security Level	Signature Size	Public Key Size	Signing Time
SLH-DSA-128s	Level 1	~7,856 bytes	32 bytes	~50ms
SLH-DSA-128f	Level 1	~17,088 bytes	32 bytes	~10ms
SLH-DSA-192s	Level 3	~16,224 bytes	48 bytes	~100ms
SLH-DSA-192f	Level 3	~35,664 bytes	48 bytes	~20ms
SLH-DSA-256s	Level 5	~29,792 bytes	64 bytes	~200ms
SLH-DSA-256f	Level 5	~49,856 bytes	64 bytes	~40ms

“s” = small signature (slow signing), “f” = fast signing (large signature)

Recommendation: Use SLH-DSA as backup to ML-DSA (conservative fallback if lattice assumptions break).

ML-DSA vs. SLH-DSA: Which to Use?

	ML-DSA	SLH-DSA
Security basis	Lattice (LWE)	Hash functions
Quantum safety	✓ Yes	✓ Yes
Signing speed	✓ Fast (~1ms)	✗ Slow (50-200ms)
Verification speed	✓ Fast (~0.5ms)	✓ Fast (~1ms)
Signature size	⚠ Large (~2.4 KB)	✗ Very large (7-50 KB)
Public key size	⚠ Large (~1.3 KB)	✓ Small (32-64 bytes)
Maturity	✓ NIST standard (2024)	✓ NIST standard (2024)
Conservative	⚠ Lattice assumptions	✓ Minimal assumptions

Primary: Use ML-DSA-65 (fast, reasonable size, quantum-safe).

Backup: Use SLH-DSA-128s (conservative, if lattice cryptography breaks unexpectedly).

Hybrid: Sign with both ML-DSA + SLH-DSA (belt-and-suspenders approach—if one breaks, other remains secure).

PQC for Verifiable Credentials: Implementation

Current State (2026)

Most verifiable credentials use:

Ed25519 (Curve25519 signatures)—fast, small, but quantum-vulnerable
ECDSA (P-256, secp256k1)—widely supported, but quantum-vulnerable
RSA (2048-4096 bit)—legacy, but quantum-vulnerable

None are quantum-safe.

Affinidi’s PQC Roadmap

Phase 1 (2026): Hybrid Signatures

Credentials signed with Ed25519 + ML-DSA-65
Verifier checks both signatures:
- Ed25519: Fast, small, works with current systems
- ML-DSA-65: Quantum-safe, future-proof
If either signature valid → credential accepted (backward compatibility)

Phase 2 (2027-2028): ML-DSA Primary

New credentials signed with ML-DSA-65 only
Legacy verifiers still accept Ed25519 (gradual migration)
Trust Registry tracks: “Issuer X uses ML-DSA” → verifiers know to expect larger signatures

Phase 3 (2029+): Post-Quantum Only

All credentials signed with ML-DSA or SLH-DSA
Ed25519/ECDSA deprecated (quantum computers pose real threat by then)
Trust Registry enforces: “Only quantum-safe signatures accepted”

DID Document with PQC Keys

Current DID document (Ed25519):

{
  "id": "did:webvh:company-x",
  "verificationMethod": [{
    "id": "did:webvh:company-x#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:webvh:company-x",
    "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"
  }]
}

Post-quantum DID document (ML-DSA):

{
  "id": "did:webvh:company-x",
  "verificationMethod": [
    {
      "id": "did:webvh:company-x#key-1",
      "type": "Dilithium3VerificationKey2024",
      "controller": "did:webvh:company-x",
      "publicKeyMultibase": "z3F... (1,952 bytes encoded)"
    },
    {
      "id": "did:webvh:company-x#key-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:webvh:company-x",
      "publicKeyMultibase": "z6MkpTHR8... (32 bytes)"
    }
  ],
  "authentication": ["#key-1", "#key-2"]
}

Hybrid approach: DID has both ML-DSA and Ed25519 keys—verifier checks both, accepts if either valid.

Migration Challenges

1. Signature Size Explosion

Problem: ML-DSA signatures are 40x larger than Ed25519 (2.4 KB vs. 64 bytes).

Impact:

QR codes: Ed25519 credential fits in QR code (≤2,953 bytes). ML-DSA credential doesn’t (too large).
NFC tags: Limited storage (≤4 KB)—ML-DSA credential barely fits, no room for multiple credentials.
Mobile bandwidth: Larger signatures = higher data transfer costs (relevant in low-bandwidth regions).

Mitigation:

Signature compression: Research into compressed lattice signatures (reduce size by 20-30%)
Detached signatures: Store signature separately, reference by hash (QR code contains hash, verifier fetches signature)
Progressive enhancement: Mobile apps prefetch ML-DSA signatures over WiFi, cache locally

2. Verification Overhead

Problem: ML-DSA verification is ~0.5ms (vs. Ed25519: ~0.1ms)—5x slower.

Impact:

High-throughput verifiers (e.g., border control scanning 1,000 passports/hour): 5x slower = longer queues
Mobile devices: Battery drain from CPU-intensive lattice operations

Mitigation:

Hardware acceleration: ARM CPUs add lattice crypto instructions (like AES-NI for AES)
Batch verification: Verify multiple ML-DSA signatures in parallel (amortize overhead)
Hybrid mode: Use Ed25519 for low-value checks (age verification), ML-DSA for high-value (passport control)

3. Backward Compatibility

Problem: Legacy systems don’t understand ML-DSA—reject credentials with unknown signature types.

Mitigation:

Hybrid signatures: Dual-sign with Ed25519 + ML-DSA (legacy systems check Ed25519, modern systems check ML-DSA)
Trust Registry flags: “Issuer X uses PQC” → verifier knows to expect ML-DSA
Gradual rollout: New issuers use PQC, old issuers keep Ed25519 (5-10 year transition period)

Cryptographic Agility: Preparing for Algorithm Transitions

Lesson from past: Algorithms break unexpectedly (MD5, SHA-1, RSA-1024 deprecated earlier than planned).

Cryptographic agility = ability to swap cryptographic algorithms without breaking systems.

Best Practices

Algorithm identifiers: Always include algorithm type in credentials:

"proof": {
  "type": "Ed25519Signature2020", // or "Dilithium3Signature2024"
  "created": "2026-07-22T00:00:00Z",
  "proofPurpose": "assertionMethod",
  "verificationMethod": "did:webvh:company-x#key-1",
  "proofValue": "z3F..."
}

Multiple verification methods: DID documents support multiple keys (Ed25519 + ML-DSA + SLH-DSA).
Trust Registry policies: “After 2030, only accept PQC signatures” (enforced centrally, all verifiers comply).
Signature suites: W3C Verifiable Credentials spec defines signature suites—pluggable crypto (swap Ed25519 for ML-DSA without changing credential structure).
Key rotation: Regularly rotate keys (every 1-2 years)—if algorithm breaks, only recent credentials affected (not 10 years of history).

Post-Quantum Timeline

Today (2026)

✅ NIST standards published (FIPS 203, 204, 205)
✅ Libraries available: liboqs (Open Quantum Safe), PQClean, BoringSSL (Google)
⏳ Early adopters: Affinidi, Signal (PQC in messaging), Google Chrome (PQC in TLS)

Near-term (2027-2029)

⏳ Hybrid deployments: Ed25519 + ML-DSA dual signatures become default
⏳ Hardware support: ARM, Intel add PQC instructions (faster lattice operations)
⏳ Browser support: Chrome, Firefox verify ML-DSA signatures natively

Mid-term (2030-2035)

⏳ PQC-only mandates: Government digital identity programs require PQC (no Ed25519/ECDSA)
⏳ Quantum computers arrive: CRQC (10,000+ logical qubits) breaks RSA-2048, ECDSA-256
⏳ Legacy algorithms deprecated: Ed25519/ECDSA sunset (all new credentials use ML-DSA)

Long-term (2035+)

⏳ Post-quantum standard: ML-DSA is the default (like RSA was 2000-2020)
⏳ Algorithm refresh: If lattice cryptography shows weaknesses, migrate to SLH-DSA or new NIST round
⏳ Quantum-safe ecosystem: DIDs, verifiable credentials, trust registries fully PQC-compliant

Affinidi’s PQC Integration

Where PQC is used:

Elements Services: Issue credentials with ML-DSA signatures
DID Documents: Support Dilithium3VerificationKey2024 type
Trust Registry: Track which issuers use PQC (flag for verifiers)
Agent Gateway: Sign agent mandates with ML-DSA (quantum-safe agent identity)

Example credential:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential"],
  "issuer": "did:webvh:company-x",
  "issuanceDate": "2026-07-22T00:00:00Z",
  "credentialSubject": { "name": "Alice", "role": "Engineer" },
  "proof": {
    "type": "Dilithium3Signature2024",
    "created": "2026-07-22T00:00:00Z",
    "verificationMethod": "did:webvh:company-x#ml-dsa-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3F... (2,400 bytes)"
  }
}

Get Started with PQC

Experiment with post-quantum signatures:

liboqs: Open-source PQC library (C, Python, Go bindings)
Affinidi SDK: Beta support for ML-DSA credential signing
NIST PQC Reference Implementations: Test vectors, reference code

Start building →

Documentation:

Technical Deep Dives

Verifiable Credentials - What PQC signatures protect
Decentralized Identifiers (DIDs) - How DIDs store PQC public keys
Zero-Knowledge Proofs - Post-quantum ZKPs (future research)

Cross-Org Agent Trust - Agent mandates signed with ML-DSA
Supply Chain Provenance - Long-lived credentials need PQC
Agent Payments - Payment mandates quantum-safe

Summary

Post-quantum cryptography (PQC) protects verifiable credentials from quantum computers:

The threat:

Quantum computers (2030-2035) will break RSA, ECDSA, Ed25519
“Store now, decrypt later” attacks compromise today’s credentials
Identity infrastructure needs quantum-safe signatures now

NIST standards (2024):

ML-DSA (FIPS 204): Lattice-based signatures, fast, ~2.4 KB signatures
SLH-DSA (FIPS 205): Hash-based signatures, conservative, ~7-50 KB signatures

Recommendation:

Use ML-DSA-65 (primary)—fast, quantum-safe, reasonable size
Use SLH-DSA (backup)—conservative fallback if lattice assumptions break
Use hybrid (Ed25519 + ML-DSA)—backward compatibility during migration

Challenges:

⚠ Large signatures (40x bigger than Ed25519)
⚠ Verification overhead (5x slower)
⚠ Backward compatibility (legacy systems don’t understand ML-DSA)

Mitigation:

Cryptographic agility (support multiple signature suites)
Hybrid signatures (dual-sign with Ed25519 + ML-DSA)
Hardware acceleration (ARM/Intel PQC instructions coming)

Where Affinidi uses PQC:

Elements Services (ML-DSA credential signing)
DID documents (Dilithium3VerificationKey2024)
Trust Registry (track PQC adoption)
Agent Gateway (quantum-safe agent mandates)

Result: Verifiable credentials remain secure even if quantum computers break classical cryptography—future-proof identity infrastructure.

Related resources

Continue learning

Products

Solutions

Deep dives

Post-Quantum Cryptography (ML-DSA, SLH-DSA)

The Problem: Quantum Computers Will Break Today’s Cryptography

What Is Post-Quantum Cryptography?

NIST PQC Standardization (2016-2024)

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

What Is ML-DSA?

ML-DSA Parameter Sets

ML-DSA Example: Signing a Verifiable Credential

SLH-DSA (Stateless Hash-Based Signature Algorithm)

What Is SLH-DSA?

SLH-DSA Parameter Sets

ML-DSA vs. SLH-DSA: Which to Use?

PQC for Verifiable Credentials: Implementation

Current State (2026)

Affinidi’s PQC Roadmap

DID Document with PQC Keys

Migration Challenges

1. Signature Size Explosion

2. Verification Overhead

3. Backward Compatibility

Cryptographic Agility: Preparing for Algorithm Transitions

Best Practices

Post-Quantum Timeline

Today (2026)

Near-term (2027-2029)

Mid-term (2030-2035)

Long-term (2035+)

Affinidi’s PQC Integration

Get Started with PQC

Related Resources

Technical Deep Dives

Related Solutions

Summary

Continue learning