Cost-benefit analysis of algorithm substitution

[Ian G <[e-mail]>]

Jon Callas wrote:
> 
> On 27 Mar 2006, at 7:44 AM, Daniel A. Nagy wrote:
> 
>> I agree with David here. The standard's purpose is to ensure
>> interoperability. It should tell us the sematics behind sequences  of 
>> bytes.
>> It is up to the implementation to make decisions based on these  
>> semantics.
>> Valid reasons to exclude certain combinations from the standard  include
>> ambiguity of interpretation, inherent insecurity or a wide  installed 
>> base of
>> incompatible implementations, but not the possibility of weird  uses, 
>> IMHO.
>>
> 
> I agree as well with both Davids.

Well, I can see I've lost the consensus battle on
this one - but I would propose that the purpose of
the ID is security, over and above interoperability,
and that is an entirely valid reason to exclude
"Weird Uses."

In general, with security, the less choice the better.

> As an observation, in 2440 one of the things we allowed was deviation  
> from DSS because the rough consensus had a certain amount of  grumpiness 
> with the US Government. In practice, hardly anyone did  anything 
> different with DSA than DSS. We even removed hash functions.
> 
> Many things have changed in the last decade, but toeing the exact  NIST 
> line or even being like them only moreso is going a bit too far.  In the 
> next decade, we're going to see a lot of advancement in hash  functions. 
> Someone is going to want to use those new hash functions  with DSA, and 
> it would be nice to be able to move faster than NIST.

As to the political circumstances of the past, it is
true that the community did certain daft things that
reduced security in response to the USG's own set of
daft things that reduced security.  It's definately
not good to follow either lead...

> Let's suppose someone comes up with a new hash function that is 251  
> bits. (I picked 251 because it's prime and less than 256.) We don't  
> want a constitutional crisis over using it. We want to be flexible  
> enough that it's pretty obvious how to extend OpenPGP to use new hash  
> functions with DSA.

It seems that PGP's design bends over backwards
to be flexible.  It's a lot of fun for crypto-
plumbers;  in fact it looks like it has been
designed as a toykit for programmers to muck
around with algorithms.

In practice, though, this flexibility seems to
rarely be used in any sensible way.

And, again, in practice, this flexibility causes
endless discussions on this mailgroup - as seen
this week - and other places where implementors
and users try and figure what goes with what.

It all takes up time from other important things.

So I guess what I'm saying is ... all this
flexibility ... how many times has it been used
to advantage, and how many times to disadvantage?

What's the cost-benefit analysis here?

iang