Crypto-Agility: Building Systems That Can Change Their Locks

History shows that no encryption method lasts forever:

• ◆DES, the US standard from 1977, used 56-bit keys. In 1998, a purpose-built machine called Deep Crack found a DES key in 56 hours.
• ◆MD5, a popular hash function, was shown to be broken in 2004. In 2012, the Flame malware used an MD5 weakness to forge a Microsoft code-signing certificate.
• ◆SHA-1 was widely used in certificates until researchers from Google and CWI Amsterdam produced the first practical SHA-1 collision, called SHAttered, in 2017.

Each time, organisations spent years finding and replacing the old algorithm. Quantum computers are simply the next, and biggest, retirement.

A crypto-agile system can change which algorithm it uses through configuration or a routine update, instead of a major rewrite. It is not a single product; it is a way of designing software, infrastructure and processes.

• ◆Shared libraries: applications call a small number of shared cryptography libraries or services instead of each building their own.
• ◆No hard-coding: algorithm choices, key sizes and certificate settings live in configuration, not scattered through source code.
• ◆Built-in negotiation: protocols like TLS 1.3 let both sides agree on the best algorithm they share, so new options can be added gradually.
• ◆An up-to-date inventory: you know where every algorithm is used, so you know what to change.
• ◆Tested change processes: you can roll out, and if needed roll back, a new algorithm safely.

The new post-quantum algorithms are young compared with RSA, which dates from 1977. Experts are confident in them, but a flaw could still be found, as happened to several competition candidates. NIST is also still adding options, such as HQC and FN-DSA. A crypto-agile organisation can adopt these, and change again if needed, with far less cost and risk.