Ben Laurie wrote:
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.

In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything needed for "pluggability" beyond versioning?

Versioning catches a large part of it, but that alone isn't always enough. Sometimes for on disk formats you need to reserve padding space to add larger or differently formatted things later.

Also support for a new crypto algorithm can actually be done without changes to the software code if it is "truely" pluggable.

An example from Solaris that is how our IPsec implementation works. If a new algorithm is available via the Solaris crypto framework in many c cases were we don't need any code changes to support it, just have the end system admin run the ipsecalgs(1M) command to update the IPsec protocol number to crypto framework algorithm name mappings (we use PKCS#11 style mechanism names that combine algorithm and mode). The Solaris IPSec implementation has no crypto algorithm names in the code base at all (we do currently assume CBC mode though but are in the process of adding generic CCM, GCM and GMAC support).

Now having said all that the PF_KEY protocol (RFC 2367) between user and kernel does know about crypto algorithms.

It seems to me protocol designers get all excited about this because

Not just on the wire protocols but persistent on disk formats, on disk is a much bigger deal. Consider the case when you have terrabytes of data written in the old format and you need to migrate to the new format - you have to support both at the same time. So not just versioning but space padding can be helpful.

Darren J Moffat

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to