SHA-1 and Git

[Perry E. Metzger]

Ben Laurie <ben at 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		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com