Cryptographic Agility in Hardware: Preparing for Post-Quantum

NIST's 2024 publication of the first post-quantum cryptography standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — marked the beginning of a multi-year transition that will affect every security system that uses public-key cryptography. For hardware security systems, this transition presents a unique challenge: hardware is hard to update, and many embedded systems deployed today will still be operating in 2035 when cryptographically relevant quantum computers may be available.

The answer to this challenge is cryptographic agility: designing security systems such that cryptographic algorithm choices are not burned into hardware in ways that cannot be updated without silicon revision. For RISC-V hardware security architects, building in agility now is an investment that will pay off when the post-quantum transition arrives at scale.

What Cryptographic Agility Means in Hardware

In software, cryptographic agility is relatively straightforward: use a well-designed cryptographic library with algorithm-agnostic APIs, and updating the underlying algorithms is a software change. In hardware, the situation is more complex because hardware acceleration for cryptographic operations is often algorithm-specific.

For RISC-V hardware security systems, cryptographic agility has several dimensions:

Algorithm negotiation: Attestation and secure communication protocols should support algorithm negotiation so that both endpoints can use the strongest mutually supported algorithm. This is already standard practice in TLS but is less commonly implemented in embedded attestation protocols.

Key size flexibility: Key storage and cryptographic hardware should be designed to accommodate larger key sizes without hardware revision. CRYSTALS-Kyber (ML-KEM) keys are significantly larger than RSA or ECDH keys. Secure key storage that was designed only for 256-bit ECC keys cannot accommodate post-quantum keys without redesign.

Software fallback: For embedded systems that cannot be revised to add post-quantum hardware acceleration, the architecture should support software-implemented post-quantum algorithms. This will be slower, but for many embedded use cases, the performance impact is acceptable.

The New NIST Post-Quantum Standards in Detail

Understanding what the NIST standards require helps hardware architects make concrete design decisions. FIPS 203 (ML-KEM, based on CRYSTALS-Kyber) is a key encapsulation mechanism for key exchange. Its key sizes range from 800 bytes (ML-KEM-512) to 1568 bytes (ML-KEM-1024) for public keys, compared to 64 bytes for a P-256 ECDH public key. Ciphertext sizes are similarly larger.

FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium) is a digital signature scheme. Signature sizes range from 2420 bytes (ML-DSA-44) to 4627 bytes (ML-DSA-87), compared to 64 bytes for an Ed25519 signature. For systems that transmit attestation tokens over constrained networks, this size increase has real bandwidth implications.

FIPS 205 (SLH-DSA, based on SPHINCS+) offers hash-based signatures with a smaller security assumption surface (only hash function security, not lattice hardness), at the cost of larger signatures: 7856-49856 bytes depending on parameter set. For embedded systems with tight bandwidth budgets, SLH-DSA may be impractical except for infrequent signing operations.

Hardware designers working on security-critical RISC-V systems should account for these size increases when sizing secure storage, communication buffers, and attestation data structures.

The "Harvest Now, Decrypt Later" Threat

The urgency of post-quantum planning for hardware security is driven by an attack strategy called "harvest now, decrypt later": an adversary captures encrypted communications today and stores them until a cryptographically relevant quantum computer is available to decrypt them.

For most data, this is a theoretical concern. For data that must remain confidential for 10-15+ years — medical records, classified information, long-term financial data — it is an immediate practical concern. Embedded systems that handle this class of data and are designed today for deployment lifecycles extending into the 2030s must account for this threat.

Attestation credentials are particularly sensitive: an attestation identity key that is compromised retroactively enables an attacker to retroactively forge attestation evidence, potentially undermining the integrity of audit logs and compliance records that depend on attestation. For this reason, we recommend that attestation identity keys be protected with hybrid classical/post-quantum key agreement from the outset of new designs.

Hardware Design Considerations for Agility

For RISC-V SoC designers building security-critical hardware today, several concrete design choices improve cryptographic agility at minimal cost:

Size key storage generously: Design OTP memory and secure key storage with headroom for post-quantum key material. The marginal cost of additional OTP rows at tape-out time is far lower than a board redesign later.

Avoid algorithm-specific hardware in the critical path: Where possible, implement cryptographic operations in security firmware on the security processor rather than in dedicated hardware accelerators. Firmware can be updated; hardware cannot. Reserve hardware acceleration for operations with hard latency requirements (e.g., AES for bulk decryption).

Design attestation token formats for extensibility: CBOR-based token formats (as used in IETF EATs) support algorithm agility natively. Avoid binary formats with hardcoded algorithm identifiers.

Plan for hybrid keys in provisioning: Design your manufacturing provisioning workflow to generate and store both classical and post-quantum key material from the start. Retrofitting post-quantum key provisioning into an existing manufacturing line is operationally complex.

A Practical Roadmap for RISC-V Platforms

For teams designing RISC-V-based security hardware today, we recommend a four-step approach to post-quantum readiness:

• Inventory current cryptographic dependencies: Map every algorithm in use and every point where algorithm choices are hardcoded or hardware-constrained
• Size key storage for post-quantum: Design secure storage to accommodate ML-KEM and ML-DSA key material, which is larger than current public-key material
• Implement hybrid key exchange: Where possible, use hybrid classical/post-quantum key exchange (e.g., ECDH + ML-KEM) in attestation and communication protocols. This provides immediate quantum resistance for harvest-now threats while maintaining compatibility with current verifiers
• Plan firmware-updateable cryptographic primitives: For operations that do not require hardware acceleration, implement in firmware to enable algorithm updates without silicon revision

The zeroRISC platform's attestation infrastructure supports hybrid key exchange and is being updated to support FIPS 203/204 natively. Contact us to discuss post-quantum migration planning for your RISC-V deployment.