Crypto Agility Starts With an Inventory, Not a Library

Every organisation now has a post-quantum migration deadline somewhere in a risk register, and most of them will start by choosing an algorithm. The first deliverable should be a list, because a migration cannot be scoped against systems nobody has written down.

What the inventory has to record

A cryptography inventory answers four questions per system:

• Where is cryptography used, including places nobody thinks of as a system, such as firmware, licence checks and device enrolment?
• Which algorithm, key size and protocol version is in use at each point?
• Which data does each use protect, and how long must that data stay confidential?
• Who can change the algorithm without a vendor, a firmware release or a hardware replacement? The last question determines cost. A TLS library upgrade is a maintenance window, while a cryptographic algorithm burned into an appliance is a procurement project.

The two clocks

Migration planning runs on two timelines. The harvest clock assumes that traffic recorded today will be decrypted once a cryptographically relevant quantum computer exists, so long-lived confidential data is exposed the moment it is transmitted. The standards clock follows the availability of approved algorithms and the deprecation dates for the current ones.
Data with a confidentiality lifetime longer than the migration window is already the urgent case, regardless of when the hardware arrives.

Where the work concentrates

Four categories usually emerge from the inventory.

• Systems with a supported upgrade path and a supplier who has published a timeline. The work is scheduling.
• Systems with a supported path but a long deprecation tail, such as TLS endpoints pinned by clients that cannot be updated quickly. The work is coordination.
• Systems with no upgrade path, which need compensating controls rather than replacement.
• Data at rest in backups and archives, which keeps its original protection long after the source system has moved.

What agility actually requires

Crypto agility is the ability to change an algorithm without redesigning the system. Three properties make that possible:

1. Algorithm identifiers are configuration rather than compiled constants.
2. Cryptographic operations sit behind an interface with more than one implementation.
3. Keys and certificates carry metadata that names their algorithm and lifetime. A system with those properties can adopt a new algorithm during a maintenance window. A system without them needs a project, and the inventory is what tells the two apart.

References

• NIST IR 8547, Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/204/final
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• ETSI, Quantum-Safe Cryptography reports: https://www.etsi.org/technologies/quantum-safe-cryptography