Crypto-Agility – The Only Way to Deploy Cryptography!br>
Stated succinctly, crypto-agility is the deployment of cryptographic schemes and mechanisms in a way that makes it easy to replace them quickly at a time of need. Anyone tracing the history of modern cryptography is well aware of the fact that cryptographic algorithms become obsolete, and minimum key lengths change over time. DES and 3DES used to be the standard symmetric encryption schemes used by everyone, but are now essentially obsolete (DES has a far too small key length, and 3DES has a too small block size for many use cases and has been replaced by AES). MD5 and SHA1 used to be the most popular hash functions but are now completely broken. RSA-1024 used to be the standard for asymmetric encryption and signing, but now 2048 is the minimum acceptable key size. Elliptic curve cryptography is quickly gaining popularity, and new curves and standards are being introduced (like the EdDSA signing algorithm over the Ed25519 curve). Finally, new attacks are discovered (like Bleichenbacher’s attack on RSA PKCS#1 v1.5 encryption, and padding oracle attacks on CBC encryption), resulting in methods changing. Everytime such a change is required, most organizations go through an excruciatingly painful process to make the change. The reasons for this are backward compatibility requirements (making any such change hard) and the fact that the specifics of the algorithm, key size and more, are often assumed to be fixed when the code was written. This means that it takes a large development effort to make these changes, and as a result, the changes are often made far too late and at great cost.
If we are to learn from history, this pattern will continue. The threat of quantum computing to modern cryptography (including Elliptic curve cryptography used in almost all cryptocurrencies) is now a hot topic of discussion. Although I personally believe that we are still far away from quantum computing being a concrete threat, we have to be ready for any eventuality; the cost of not being ready is just way too high! However, this is not the only reason that cryptography is going to be changing over the coming years. The blockchain and cryptocurrency communities are developing fast, with different algorithms being used and proposed (for just one example, BLS or Schnorr, instead of ECDSA), and different curves may be proposed. The question we must all ask ourselves is how long will it take us to respond to changes, and will we be ahead of the curve or lagging far behind? If we are not crypto-agile, and our platforms are tightly bound to the way a specific currency works, from its ledger structure to the details of its digital signature scheme, then making changes to add new currencies and update existing currencies will be painful and slow. Crypto-agility is essential in this market, in exactly the same way that it is essential in the enterprise security space.
Assuming that you are convinced that this is important, you may be thinking about how to be crypto-agile, or what it means in concrete terms. In general, the more abstract you make your cryptographic code, the more agile you will be. For example, if a generic signature scheme class is defined, and no particulars at all are known about it, then the concrete signature itself can be easily replaced. However, it is often the case that the highest level of abstraction comes at a cost (the length of the result is not known, it is not possible to break it up into a “hash the message” step followed by a “sign the hash” step, preventing optimizations like hashing the message before sending it to be signed, and so on). The balance between crypto-agility and well-functioning code is very application specific, and one that needs to be determined by every organization individually. Thus, there are no easy answers here. Nevertheless, by being aware of the cost involved in not being agile, an informed decision can be made hopefully resulting in a good balance.
Another issue that needs to be considered from the outset is secure updates and dealing with backward compatibility. When writing your application, assume that security bugs will be discovered at some level, and updates will be required. Think about how this process will be carried out securely, and how backward compatibility will be dealt with in a manner that won’t allow a man-in-the-middle attacker to carry out a roll-back attack (in a roll-back attack, the adversary manages to trick two devices that are both running the new version that each one is interacting with a device running an old version, with the result being that both run the old version).
If you keep all of the above in mind, then you’ll be very thankful when history repeats itself and your cryptography needs to be quickly updated – either because of new vulnerabilities and attacks, or because the ability to adopt new methods will enable you to be ahead of the pack and grow your business.