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

For instance:


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



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

  • $\begingroup$ I don't know, but there is anyway the term "key agility", see schneier.com/paper-aes-agility.pdf $\endgroup$ Commented Dec 4, 2015 at 14:29
  • $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes
    Commented Dec 4, 2015 at 15:48
  • $\begingroup$ 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 $\endgroup$ Commented Apr 18, 2017 at 14:24

1 Answer 1


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

Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-1AndMGF1Padding");

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.

  • 2
    $\begingroup$ 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 $\endgroup$
    – Maarten Bodewes
    Commented Dec 4, 2015 at 15:38
  • $\begingroup$ It's still a valid example otherwise of course. There are other issues like this. I like that you specified a protocol and an API. $\endgroup$
    – Maarten Bodewes
    Commented Dec 4, 2015 at 15:43
  • 3
    $\begingroup$ Another concern is downgrade attacks. If both sides of a client/server system are forced to support legacy cryptographic protocols, because some clients/servers haven't updated, even a pair of modern implementations can be tricked into falling back to an insecure ciphersuite. See recent TLS attacks involving export-grade ciphers. $\endgroup$ Commented Dec 4, 2015 at 22:58
  • 1
    $\begingroup$ Crypto agility is really important. However, systems aren't really agile and that's the problem. Crypto agility doesn't mandate supporting legacy systems. It means that you can easily update your system to change the primitive. $\endgroup$ Commented Dec 7, 2015 at 16:31
  • 2
    $\begingroup$ From a software engineering point of view you are of course correct (especially when doing "agile" programming, which is in some sense the opposite of "agile crypto"). The problem is that the result of this is that primitives are not replaced since they are so intertwined. I think that this could be greatly helped by having a very high level API only that has many fewer options. It also depends very much if we are talking about TLS that has to have great interoperability or your own code in your own application. Anyway, not enough space here for a real discussion... $\endgroup$ Commented Dec 7, 2015 at 20:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.