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

Jon Callas jon at callas.org
Wed Aug 26 18:12:29 EDT 2009


On Aug 25, 2009, at 4:44 AM, 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?

I have no idea, myself.

I have said many times effectively what you said, and there's always  
the same hand-wringing.

I believe that it boils down to this:

They aren't software engineers and we are. We've designed  
paramaterized or (that's or, not xor) versioned protocols before.  
We've done upgrades.

They will inevitably bring up downgrade attacks, but come on. It is a  
truism that there is more stupidity than malice in the world and if  
you stupid-proof your protocol, you've also malice-proofed it.

And yes, yes, one has to be thorough in your design of plugable  
system. I, too, can come up with a scenario where a simple version  
number is not enough. It's just a software engineering problem, and  
you and I and the other software engineers know how to do software  
engineering.

I think that again, they haven't in general deployed software to a  
population large enough to contain stupid people. If they have  
deployed it to stupid people, they haven't had the attitude that  
stupidity is a fact of life and has to be fixed in the software, not  
the person.

And after boiling it down, let me go further and reduce it to a  
sticky, bitter sauce:

They don't believe it's important. They so believe the naive simple-is- 
better line that they end up believing that brittle is better than  
resilient. They're so enamored with the aphorism that you can make  
something so simple it's secure or so complex it's secure that they  
forget the aphorism that you should make things as simple as possible  
and no simpler. They're not engineers, so for them, upgrades are free.  
Therefore brittle is simpler than resilient.

	Jon

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



More information about the cryptography mailing list