# What is cryptographic agility?

I keep seeing the term "Cryptographic Agility" referenced. What does it mean?

For instance:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb204775(v=vs.85).aspx

One of the key value propositions of CNG is cryptographic agility, sometimes called cryptographic agnosticism.

http://research.microsoft.com/apps/pubs/default.aspx?id=121045

https://media.blackhat.com/bh-us-10/whitepapers/Sullivan/BlackHat-USA-2010-Sullivan-Cryptographic-Agility-wp.pdf

The second source suggests that it means multiple encryption algorithms can use the same key. Is this true?

## migrated from security.stackexchange.comDec 4 '15 at 6:45

This question came from our site for information security professionals.

• I don't know, but there is anyway the term "key agility", see schneier.com/paper-aes-agility.pdf – Mok-Kong Shen Dec 4 '15 at 14:29
• @Mok-KongShen That's something quite unrelated, it discusses the speed for sub-key derivation for symmetric ciphers, i.e. the time it costs to "initialize" the cipher with a specific key. Personally I think that Schneier should have made this more clear in the document, I could also think of "key agility" of the possibility to use keys stored in various locations. – Maarten Bodewes Dec 4 '15 at 15:48
• Thanks to this thread I now understand what people refer to by "cryptographic agility". However, I have the impression that several things mix up here. 1. Cryptographic agility means that we can replace primitives by new ones without having to redesign the entire application/protocol/scheme. 2. Moreover, we'd want a plug-and-play way of putting things together. 3. Libraries often provide a bunch of primitives which are typically combined under some compatibility conditions between the various primitives. 4. Ideally, the way a library combines the primitives should come with a security reductio – Michael Nüsken Apr 18 '17 at 14:24

Cryptographic agility is the capacity for an IT system to easily evolve and adopt alternatives to the cryptographic primitives it was originally designed to use.

An example (and building block) for cryptographic agility is the X.509 certificate format, which is defined with various signature algorithms, hash algorithms, and key sizes, in a manner allowing in principle future growth.

Another is crypto provider APIs, such as Java's com.sun.crypto.provider.

A huge drawback of cryptographic agile systems is their complexity, leading to implementation and usage errors, incompatibilities and hasty workarounds for these, all conspiring to create security issues; examples abound. Also, the supposed agility often fails as soon as it is needed.

As an example of the later that recently hit me, consider code using Java's com.sun.crypto.provider made some time ago, invoking a cipher with

and having made the string parameterizable. Now, because SHA-1 collision resistance is broken, some authority says that it must be replaced with SHA-256 everywhere including in that application (notwithstanding the fact that SHA-1 remains perfectly safe in that application, as far as we know). So, we change the parameterizable string to "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" and are flying, right? Er, no. It turns out that MGF1 stands for a mask generating function that uses a hash, which remains SHA-1 by default, and there is no such thing as "RSA/ECB/OAEPWithSHA-256AndMGF1WithSHA-256Padding", or hope that it will be added soon to com.sun.crypto.provider (see this answer for details); so you have to change the code anyway, plus add a lot of new messy non-standard things all around to have the hash parameterizable as a single string, as the IT system requires.
And there are other more subtle issues, including this (potential) security one: by using SHA-256, all things being equal, we reduce the message capacity for a single RSA block, and it is likely hard to rule out that com.sun.crypto.provider, or some other, will happily and transparently add a second block oblivious to us; thus we might end up with two RSA blocks, and that could well create a vulnerability that did not previously exist.
Proponents of cryptographic agility could understandably object to this line of thought that if com.sun.crypto.provider was more crypto-agile, the argument would fall apart.
• That would be the case if "RSA/ECB" actually implemented ECB, but it doesn't. You can only encrypt a single block with it. It should have been named "RSA/None" - for the Oracle provided provider anyway :P – Maarten Bodewes Dec 4 '15 at 15:38