SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)

Thor Lancelot Simon tls at rek.tjls.com
Tue Aug 25 13:54:32 EDT 2009


On Tue, Aug 25, 2009 at 12:44:57PM +0100, 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?
> 
> 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?

Look at the difference between the time it requires to add an algorithm
to OpenSSL and the time it requires to add a new SSL or TLS version to
OpenSSL.  Or should we expect TLS 1.2 support any day now?  If earlier
TLS versions had been designed to allow the hash functions in the PRF
to be swapped out, the exercise of recovering from new horrible problems
with SHA1 would be vastly simpler, easier, and far quicker.  It is just
not the case that the software development exercise of implementing a
new protocol is on a scale with that of implementing a new cipher or hash
function -- it is far, far larger, and that, alone, seems to me to be
sufficient reason to design protocols so that algorithms and algorithm
parameter sizes are not fixed.

Thor

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



More information about the cryptography mailing list