# Cryptographic agility

In cryptographic protocol design, cryptographic agility or crypto-agility is the ability to switch between multiple cryptographic primitives.
A cryptographically agile system implementing a particular standard can choose which combination of primitives to use. The primary goal of cryptographic agility is to enable rapid adaptations of new cryptographic primitives and algorithms without making disruptive changes to the system's infrastructure.
Cryptographic agility acts as a safety measure or an incident response mechanism for when a cryptographic primitive of a system is discovered to be vulnerable. A security system is considered crypto-agile if its cryptographic algorithms or parameters can be replaced with ease and is at least partly automated. The impending arrival of a quantum computer that can break existing asymmetric cryptography is raising awareness of the importance of cryptographic agility.

## Example

The X.509 public key certificate illustrates crypto-agility. A public key certificate has cryptographic parameters including key type, key length, and a hash algorithm. X.509 version v.3, with key type RSA, a 1024-bit key length, and the SHA-1 hash algorithm were found by NIST to have a key length that made it vulnerable to attacks, thus prompting the transition to SHA-2.

## Importance

With the rise of secure transport layer communication in the end of the 1990s, cryptographic primitives and algorithms have been increasingly popular; for example, by 2019, more than 80% of all websites employed some form of security measures. Furthermore, cryptographic techniques are widely incorporated to protect applications and business transactions.
However, as cryptographic algorithms are deployed, research of their security intensifies, and new attacks against cryptographic primitives (old and new alike) are discovered. Crypto-agility tries to tackle the implied threat to information security by allowing swift deprecation of vulnerable primitives and replacement with new ones.
This threat is not merely theoretical; many algorithms that were once considered secure (DES, 512-bit RSA, RC4) are now known to be vulnerable, some even to amateur attackers. On the other hand, new algorithms (AES, Elliptic curve cryptography) are often both more secure and faster in comparison to old ones. Systems designed to meet crypto-agility criteria are expected to be less affected should current primitives be found vulnerable, and may enjoy better latency or battery usage by using new and improved primitives.
For example, quantum computing, if feasible, is expected to be able to defeat existing public key cryptography algorithms. The overwhelming majority of existing public-key infrastructure relies on the computational hardness of problems such as integer factorization and discrete logarithms (which includes elliptic-curve cryptography as a special case). Quantum computers running Shor's algorithm can solve these problems exponentially faster than the best-known algorithms for conventional computers. Post-quantum cryptography is the subfield of cryptography that aims to replace quantum-vulnerable algorithms with new ones that are believed hard to break even for a quantum computer. The main families of post-quantum alternatives to factoring and discrete logarithms include lattice-based cryptography, multivariate cryptography, hash-based cryptography, and code-based cryptography.

## Awareness

System evolution and crypto-agility are not the same. System evolution progresses on the basis of emerging business and technical requirements. Crypto-agility is related instead to computing infrastructure and requires consideration by security experts, system designers, and application developers.

## Best practices

Best practices about dealing with crypto-agility include:
* All business applications involving any sort of cryptographic technology should incorporate the latest algorithms and techniques.
* Crypto-agility requirements must be disseminated to all hardware, software, and service suppliers, who must comply on a timely basis; suppliers who cannot address these requirements must be replaced.
* Suppliers must provide timely updates and identify the crypto technology they employ.
* Quantum-resistant solutions should be kept in mind.
* Symmetric-key algorithms should be flexible in their key lengths.
* Hash algorithms should support different lengths of outputs.
* Digital certificate and private key rotations must be automated.
* Standards and regulations must be complied with.
* The names of the algorithms used should be communicated and not assumed or defaulted.

## Other designs

Cryptographic agility typically increases the complexity of the applications that rely on it. Developers need to build support for each of the optional cryptographic primitives, introducing more code and increasing the chance of implementation flaws as well as increasing maintenance and support costs. Users of the systems need to select which primitives they wish to use; for example, OpenSSL users can select from dozens of ciphersuites when using TLS. Further, when two parties negotiate the cryptographic primitives for their message exchange, it creates the opportunity for downgrade attacks by intermediaries (such as POODLE), or for the selection of insecure primitives.
One alternative approach is to dramatically limit the choices available to both developers and users, so that there is less scope for implementation or configuration flaws. In this approach, the designers of the library or system choose the primitives and do not offer a choice of cryptographic primitives (or, if they do, it is a very constrained set of choices). Opinionated encryption is visible in tools like Libsodium, where high-level APIs explicitly aim to discourage developers from picking primitives, and in Wireguard, where single primitives are picked to intentionally eliminate crypto-agility.
If opinionated encryption is used and a vulnerability is discovered in one of the primitives in a protocol, there is no way to substitute better primitives. Instead, the solution is to use versioned protocols. A new version of the protocol will include the fixed primitive. As a consequence of this, two parties running different versions of the protocol will not be able to communicate.