Ben Laurie <b...@links.org> 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 unconfigurable. > 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. Perry -- Perry E. Metzger pe...@piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com