Post-Quantum Cryptography for AI Agent Identity

The Quantum Clock Is Already Ticking

The AI agent identity systems we deploy today will still be operating when cryptographically relevant quantum computers arrive. Current estimates from NIST and the broader cryptographic community place this timeline somewhere between 2030 and 2040 — but the threat model demands action now.

Here is why: agent identity records, delegation tokens, and audit trails are long-lived artifacts. An Action Receipt chain generated in 2026 may need to be verified in 2036 as part of a regulatory audit or incident investigation. If those receipts were signed with algorithms that a quantum computer can break, the entire audit trail becomes unverifiable. The cryptographic assurance that “Agent X performed Action Y under Delegation Z” evaporates.

This is the “harvest now, decrypt later” problem applied to identity infrastructure. An adversary who captures signed agent communications today can store them and forge signatures once quantum computing matures. For agent identity systems carrying delegation chains and audit trails with legal or regulatory significance, this is not an acceptable risk.

Why NIST Chose ML-DSA (and Why We Follow)

In August 2024, NIST published FIPS 204, standardising ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly known as CRYSTALS-Dilithium) as the primary post-quantum signature scheme. ML-DSA was selected after years of rigorous evaluation through the NIST Post-Quantum Cryptography Standardization Process.

ML-DSA comes in three parameter sets:

Parameter Set	Security Level	Public Key	Signature	Use Case
ML-DSA-44	NIST Level 2	1,312 bytes	2,420 bytes	General use
ML-DSA-65	NIST Level 3	1,952 bytes	3,309 bytes	Recommended default
ML-DSA-87	NIST Level 5	2,592 bytes	4,627 bytes	High security

IDProva uses ML-DSA-65 as its post-quantum component, providing NIST Level 3 security. This means an attacker would need to solve a lattice problem equivalent to breaking AES-192 — a level that provides substantial margin against both classical and quantum attacks.

The Hybrid Approach: Ed25519 + ML-DSA-65

IDProva does not replace Ed25519 with ML-DSA-65. It uses both, simultaneously. Every signature is a hybrid combining:

• Ed25519 (RFC 8032): 64-byte signatures, ~128-bit classical security, decades of cryptanalytic scrutiny
• ML-DSA-65 (FIPS 204): 3,309-byte signatures, NIST Level 3 quantum security, newer but NIST-standardised

The hybrid signature generation works as follows:

HybridSign(message, sk_ed25519, sk_mldsa65):
  sig_classical = Ed25519_Sign(sk_ed25519, message)    // 64 bytes
  sig_quantum   = MLDSA65_Sign(sk_mldsa65, message)    // 3,309 bytes
  return CBOR_Encode({
    "ed25519": sig_classical,
    "mldsa65": sig_quantum,
    "version": 1
  })                                                    // ~3,400 bytes

Verification requires both signatures to be valid. An attacker must break Ed25519 and ML-DSA-65 to forge a signature. This provides defense in depth: if either algorithm is found to have an unexpected weakness, the other still provides security.

The Size Tradeoff

The most visible cost of post-quantum cryptography is size. Compare the raw numbers:

Component	Ed25519 Only	Hybrid (Ed25519 + ML-DSA-65)	Increase
Public key	32 bytes	1,984 bytes	62x
Signature	64 bytes	~3,400 bytes (CBOR-encoded)	53x

These numbers look dramatic in isolation. In practice, the impact is manageable for agent identity use cases:

DID Documents are fetched once and cached. A DID Document with a hybrid key is roughly 2 KB larger than a classical-only document. With the recommended 5-minute cache TTL, this is negligible overhead.

Delegation Attestation Tokens (DATs) are created infrequently relative to the actions they authorise. A single DAT might authorise thousands of actions over its lifetime. The additional 3.3 KB per DAT is amortised across all those actions.

Action Receipts are where size matters most, since they are generated per-action. However, receipts are typically stored rather than transmitted in real-time. Storage is cheap. The cost of unverifiable audit trails when quantum computers arrive is not.

For bandwidth-constrained environments, IDProva’s protocol supports a classical-only mode where only Ed25519 signatures are used. This is an explicit tradeoff: implementations operating in classical-only mode cannot claim trust levels above L2, and verifiers will note the reduced security posture.

IDProva’s PQC Migration Roadmap

IDProva takes a phased approach to post-quantum migration, aligned with the broader industry transition timeline:

Phase 0: Hybrid Default (2026 — Current)

The current state. Hybrid Ed25519 + ML-DSA-65 is the recommended default. Classical-only fallback is permitted for environments that cannot yet support ML-DSA-65.

All new implementations SHOULD generate both Ed25519 and ML-DSA-65 keypairs. DID Documents SHOULD include both key types. Signatures SHOULD use the hybrid scheme.

Phase 1: Classical-Only Deprecated — Advisory (2027)

Classical-only mode is flagged as weakening. All new agent identities MUST include ML-DSA-65 keys. Existing classical-only agents are advised to rotate to hybrid keys.

Registries begin tracking the ratio of hybrid vs. classical-only identities. Monitoring dashboards highlight classical-only agents as security advisories.

Phase 2: Classical-Only Deprecated — Warning (2028)

Verifiers SHOULD reject classical-only signatures in high-assurance contexts. Trust level assessments penalise classical-only agents. The IDProva specification formally deprecates classical-only mode with a defined sunset date.

Phase 3: Next-Generation Evaluation (2029+)

Evaluate ML-DSA-87 as the default PQC parameter set for environments requiring higher security margins. Assess ML-KEM (FIPS 203) for key exchange in agent-to-agent encrypted channels. Monitor NIST’s ongoing evaluation of additional post-quantum algorithms.

Why “Bolt-On Later” Fails

Some argue that post-quantum cryptography is premature for agent identity systems — that it is better to deploy with classical algorithms now and migrate later when quantum computers are closer to reality.

This argument underestimates the cost of migration in identity infrastructure:

Identity re-issuance. Every agent DID Document must be updated with new keys. Every controller must regenerate keypairs. For large deployments, this is an operational project measured in months.

Delegation chain breakage. Existing DATs are signed with classical keys. They cannot be “upgraded” — they must be re-issued. Any active delegation chains must be reconstructed from root to leaf.

Audit trail integrity. Action Receipts signed with classical algorithms remain vulnerable to quantum forgery. The historical audit trail — potentially years of compliance-critical records — becomes cryptographically suspect. There is no way to retroactively add quantum resistance to already-signed records.

Harvest-now attacks. If an adversary has been capturing signed agent communications (DATs, receipts, DID updates), they can forge identities and fabricate audit records once they have quantum computing capability. This is not a theoretical attack — nation-state adversaries are known to be stockpiling encrypted and signed data.

The cost of hybrid signatures today — larger keys, larger signatures, slightly more computation — is a rounding error compared to the cost of a forced migration under time pressure later.

Getting Started with PQC in IDProva

IDProva’s CLI and Rust SDK handle hybrid cryptography transparently:

# Generate a hybrid keypair (Ed25519 + ML-DSA-65)
idprova keygen --output ~/.idprova/keys/agent.key

# Create an AID with hybrid keys (both key types included automatically)
idprova aid create \
  --id "did:idprova:example.com:secure-agent" \
  --name "Quantum-Ready Agent" \
  --controller "did:idprova:example.com:admin" \
  --key ~/.idprova/keys/agent.key

The hybrid scheme is the default. No special flags or configuration required. Developers interact with the same API regardless of whether they are using classical-only or hybrid mode — the cryptographic complexity is encapsulated in the protocol layer.

Conclusion

Post-quantum cryptography is not a feature to be added to agent identity systems eventually. It is a foundational design decision that must be made at the beginning. The cost of getting it wrong — unverifiable audit trails, forgeable delegation chains, compromised identity records — far exceeds the cost of slightly larger signatures today.

IDProva makes the right choice easy: hybrid cryptography by default, a clear migration roadmap, and a protocol designed for cryptographic agility as the post-quantum landscape evolves.

Read the full Cryptography specification or get started with quantum-ready agent identity today.