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
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.