A naive approach would be to just review the source code and search for cryptographic calls. However, this is both time-consuming and error-prone: what will the parameters be when this function is actually called? Which provider will respond to the call? Are we sure this isn’t dead code or an unused part of a library? On top of this, a lot of crypto in large applications is called by third party intermediate libraries and components of application frameworks for which source code might not even be available.
A recent NIST paper recommending which steps to take to prepare for the advent of quantum computers proposes that users of cryptography look to achieve ‘crypto agility’ as soon as possible. The idea was further expanded by Gartner in a recent research note, and now crops up regularly. It’s sometimes described as ‘crypto-agnosticism’, but what does it mean, and how does one achieve it?
Designers of cryptographic protocols have talked for a long time about the idea of algorithm agility. The principle is simple: that a protocol will be designed in such a way that its function is, to some extent, independent of the choice of cryptographic algorithm used, therefore allowing you to switch algorithm. You might even have a set of recommended cipher suites that can be negotiated in each protocol exchange – this is how TLS works for example. There are now whole RFCs dedicated to the topic.
Crypto agility extends this idea from network protocols to all of the cryptography in use in an organisation. This means that an organisation can only become crypto-agile when the security team knows all of the algorithms, keylengths, crypto libraries and protocols in use in their applications and infrastructure, and has a plan that would allow them to change if necessary.