Crypto-agility as an architecture property

Most systems cannot change cryptographic algorithm because of a column width. A signature column sized for an elliptic curve scheme holds a few dozen bytes. A post-quantum signature is measured in kilobytes. The algorithm swap itself is a one-line change in a library. The column, the index on it, the message format that carries the value, the smartcard that stores the key and the printed code that has to encode it are five separate pieces of work owned by five different people. Crypto-agility is the property of having dealt with those five in advance.

The three places rigidity hides

Data at rest is the first. A stored ciphertext with no algorithm identifier and no format version can only be migrated by a flag day: stop the system, convert everything, start again, and hope the volume estimate was right. An envelope that records how the payload was protected and with which key turns the same migration into a background job that can run for a month and be paused when the batch window is tight.

The wire is the second. Protocols where the algorithm is implied by the version number force both ends to move on the same day, which is impossible when one end belongs to a partner or a regulator. Negotiation is what buys a phased migration.

The code is the third and the most common. If a call into a crypto library appears in forty places across the business logic, each with its own parameters, there is no single point at which anything can be changed. That pattern is usually the residue of one integration written under time pressure and copied by the next person with a deadline.

What agility looks like in a codebase

• Every stored ciphertext and signature carries an algorithm identifier, a key identifier and a format version.
• Key material is reached through one interface. Business logic never names an algorithm and never sees a key.
• Buffer and field sizes are derived from the algorithm in use, with headroom, rather than written as constants.
• Verification accepts more than one algorithm at a time, because a migration means both are live for months and probably years.
• There is a re-encryption path for data at rest that somebody has actually run, with throughput measured on real volumes.
• Tests are parameterised over the set of supported algorithms, so adding one is a configuration change that runs the whole suite.

The fourth item is the one teams skip, and it is the one that decides whether the migration is a project or a crisis. During the transition every consumer must verify signatures made under both the old and the new scheme, including consumers written by other people. A design that assumes a single active algorithm has assumed the one condition that will not hold on the day it matters.

The honest cost

This is not free. An indirection layer is another interface for the next engineer to learn and another place to get key handling wrong, which is a category of bug with unusually bad consequences. Systems have been made worse by an abstraction built to be agile about something that was never going to change.

The judgement is about the lifespan of the data rather than the lifespan of the code. An internal tool holding nothing that matters in a year can name its algorithm inline, as long as that was a decision rather than a default. A system holding land records, health records, identity enrolment or anything that must stay confidential into the 2040s has already lost that argument, and the only question is when the bill arrives.

The same reasoning applies to records that must be verifiable rather than secret. Our first production ledger went live in 2016. The append-only systems we still maintain from that period divide neatly: those with a version field in the record header can take a new signature scheme in a release, and those without cannot change at all without rewriting history somebody has already relied on. Immutability is a fine property until it means the format cannot be extended.

The test we use is easy to state and uncomfortable to run: how long would it take to change the signature algorithm on one production system, end to end, including everything already signed and every consumer that verifies it? On most estates nobody can answer, and where somebody can, the answer is longer than the window they are planning against. That gap is the work.