Are you ready for the next big thing in cryptography?

Actually, it’s a trick question. Ask 5 different people what the “next big thing” will be and you’ll get at least 5 different answers. Will quantum computing become a reality? Will the theoretical weaknesses in SHA-2 become practical? Will there be another Heartbleed? Another SPECTRE? None of these may happen in the next 5 years, or one or more of them may happen in the next 6 months. The real question is, are you ready for change?

Because there’s nothing techies like more than jargon, we have a term for this. Cryptographic agility, or cryptoagility for short, is the ability to easily make changes to the cryptographic algorithms and protocols used in a system. It’s a generalization of the more common notion of key agility, which is the ability to swap out a key that has been compromised, or better still, to swap it out after a set period, before it gets compromised.

An approach many systems take is to be flexible in the cipher suites they support, and to have suite negotiation be a part of communication protocols. TLS is a classic example. But cipher suite flexibility only translates to cryptoagility if one has the resources to support newer suites as they become available. Some systems are too constrained to have multiple cryptographic implementations. This only gets worse if one has to take into account white-box attacks, because cryptographic implementations that are white-box attack resistant tend to be considerably more resource intensive already.

If we make the restriction that a given version of the system can only support one crypto algorithm of each “type” (e.g. one block cipher, one key exchange implementation, etc.), because of resource constraints, then it stands to reason that cryptoagility necessarily means swapping out one implementation for another.

Let’s consider how a cryptographic library would need to be arranged so that it was as easy as possible to update algorithmic choices from one version of a system to the next:

  1. No hard-coded sizes. It should be possible to use library functions to learn the expected sizes of outputs, for which space may need to be allocated, as well as inputs such as key length, if keys need to be generated. If sizes need to be hard-coded in the application, even as macros, then moving from, say, 128-bit AES to 256-bit AES will require code changes.
  2. API consistency. If the number, type, and order of parameters is not identical across all algorithms of a given type, then changing algorithms necessarily means changing code, possibly significantly. For example, SHA2-256 processes its input 32 bits at a time, while SHA2-512 processes its input 64 bits at a time. Imagine the difficulty moving from SHA2-256 to SHA2-512 if this difference is exposed at the API level.
  3. API abstraction and build-time parameterization. We can take API consistency one step further by envisioning a library where all algorithms of a given type are actually called via the same abstract API, with the specific algorithm choice made not at coding time, but at build time. In other words, using compile-time macros, or special tooling (which may provide a better user experience), the library user can decide on algorithms, modes, key sizes etc. as part of their build process, meaning cryptoagility can be achieved without changing a single line of code.
  4. Implementation diversity. When white-box attacks are relevant, staying ahead of security issues does not always mean changing algorithms, it may mean changing implementations of the same algorithm. The cryptographic library provider must support a means of diversifying their white-box cryptographic implementations. For maximum agility, the user should be able to create diverse instances on-premise and with “the flick of a (software) switch”.

So, are you ready for change? Ask your crypto provider if their approach to cryptoagility addresses resource constrained, white-box environments, and whether updates mean slogging through code, or simply updating a build script.

It’s a dangerous (crypto) world out there, stay safe and be agile (or cryptoagile)!

For more detail about why software protection is important in cybersecurity today, please read our Cloakware® Report, Edition 1.  If you’re interested in more articles about cybersecurity issues and strategies please be sure to Subscribe!


Note: Irdeto provides a range of software security products and services based off of our Cloakware® Software Protection suite of tools and technologies.  All of the solutions, including Cloakware’s Secure Environment, adopt a multi-layered, self-protecting, approach to software security.