14

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

For instance:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb204775(v=vs.85).aspx

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

http://research.microsoft.com/apps/pubs/default.aspx?id=121045

https://media.blackhat.com/bh-us-10/whitepapers/Sullivan/BlackHat-USA-2010-Sullivan-Cryptographic-Agility-wp.pdf

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

Patriot
  • 3,132
  • 3
  • 18
  • 65
LazerSharks
  • 303
  • 2
  • 6
  • I don't know, but there is anyway the term "key agility", see http://www.schneier.com/paper-aes-agility.pdf – Mok-Kong Shen Dec 04 '15 at 14:29
  • @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. – Maarten Bodewes Dec 04 '15 at 15:48
  • 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 – Michael Nüsken Apr 18 '17 at 14:24

1 Answers1

8

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.

Community
  • 1
fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • 2
    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 – Maarten Bodewes Dec 04 '15 at 15:38
  • 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. – Maarten Bodewes Dec 04 '15 at 15:43
  • In your last sentence, did you mean to say cryptographic agility proponents will regard com.sun.crypto.provider as not crypto-agile, or crypto-agile? – LazerSharks Dec 04 '15 at 21:22
  • 3
    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. – Stephen Touset Dec 04 '15 at 22:58
  • 1
    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. – Yehuda Lindell Dec 07 '15 at 16:31
  • @Yehuda Lindell: thanks for first two sentences in your comment making the last one in my answer a fulfilled prophecy ;-) I largely agree with you. My view is that the architecture should be agile, which tends to go along built using clearly defined building blocks; but it is better to have a well-defined gizmo doing a simple thing, than a would-be-do-it-all which, if future repeats the past, won't do the next thing required, and (because of its complexity) will be more brittle. – fgrieu Dec 07 '15 at 17:04
  • 2
    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... – Yehuda Lindell Dec 07 '15 at 20:03
  • Just a side note... This answer indicates that hashing collisions are an issue for padding, but I don't think that's true. I'm not sure you would ever need to switch from SHA-1 to SHA-256. – Richard Brightwell Apr 30 '17 at 05:08
  • @Richard Brightwell: I'm not saying that there is any real weakness in MGF1 with SHA-1. But using SHA-1 raises questions in a certification process, and that's a good operational reason to replace it with SHA-256. – fgrieu Apr 30 '17 at 10:42