[Cryptography] a question on consensus over algorithmic agility

John Kelsey crypto.jmk at gmail.com
Thu Jun 26 17:21:44 EDT 2014


There are a couple point I think are really important to think about if you're trying to get algorithm agility in a protocol:

a.  The security benefit of algorithm agility is entirely in being able to *stop* using some algorithms while still functioning.  

This means that you only really get this benefit if you have at least two ciphersuites that are both SHALLs.  If everyone implements RC4 + CRC32 (the SHALL), and some people also implement AEC-GCM (the SHOULD), then when someone finally realizes that RC4+CRC32 is insecure, you can't actually get rid of it.  Indeed, version rollback attacks will work even on implementations that support AES-GCM, because they have to be able to interoperate with implementations that don't.  

b.  A lot of the time, the "algorithm" that gets broken isn't a cryptographic primitive like AES, but rather some surrounding chaining mode or padding scheme or something.  

This means that if there are two ciphersuites, they should be pretty different to minimize the overlap between them.  For example, you might do AES-GCM and 3DES-CBC+HMAC-SHA256.  The same idea applies to more ciphersuites.  

c.  It's critical to make sure there's a simple way for a particular implementation to stop using a given algorithm, and that this is built into the protocol.  The ciphersuite negotiation probably needs to be really simple.  

Comments?

--John


More information about the cryptography mailing list