At 9:39 AM -0400 8/25/09, Perry E. Metzger wrote:
>Ben Laurie <> writes:
> > 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?
>For one example, it is not theoretical that some people will often want
>to use different algorithms than others and will need negotiation. Some
>things like SSH have approximately done this right. Others have done
>this quite wrong.
>When we were planning out IPSec, a key management protocol, SKIP, was
>proposed that had no opportunity for negotiating algorithms at all --
>they were burned into the metal. As it happens, by now we would have had
>to completely scrap it.
>Of course you can go too far in the other direction. IPSec is a total
>mess because there are far too many choices -- the standard key
>management protocols are so jelly-like as to be incomprehensible and

Perry is completely correct on the two previous paragraphs. Hard-coded 
algorithms, particularly asymmetric encryption/signing and hash algorithms, 
will lead to later scrapping and a transition for the entire protocol. But it 
is quite easy to build a protocol with too many knobs, and IPsec is living 
proof of that. TLS's fixed, registered ciphersuites are far from perfect, but 
in retropsect, they seem a lot better from an operations / deployment 
standpoint than IPsec.

> > It seems to me protocol designers get all excited about this because
> > they want to design the protocol once and be done with it. But software
> > authors are generally content to worry about the new algorithm when they
> > need to switch to it - and since they're going to have to update their
> > software anyway and get everyone to install the new version, why should
> > they worry any sooner?
>You speak of "beyond versioning" as though introducing versioning or
>algorithm negotiation were a trivial thing, but I don't think you can
>generally tack such things on after the fact. You have to think about
>them carefully from the start.

A different answer to Ben would be "because not planning sooner causes your 
software users more grief". If you build in both algorithm agility and a few 
probably-good algorithms, the operational changes needed when one algorithm 
fails is low. Later software updates that contain other changes can also 
include new algorithms that are suspected to be good even if all of the 
original ones fail.

--Paul Hoffman, Director
--VPN Consortium

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

Reply via email to