A question about Camellia

[David Shaw]

On Jan 24, 2009, at 1:29 PM, Robert J. Hansen wrote:

> David Shaw wrote:
>> But then, once we have algorithm agility, that means we must have a
>> means for dealing with that agility (preference lists being the
>> defined OpenPGP mechanism for that).  And then, having such means,
>> why do we care all that much whether an algorithm is present or not?
>
> To quote one of the best, most promising, and most vastly underused,
> statements in engineering:
>
> Hmm.  I need to think about that...
>
>> Do we want to add every cipher that comes down the pike?  Certainly
>> not.  Do we want to add well designed ciphers that have strong
>> evidence behind them?  Maybe, but still, why bother?   We have that
>> already.  Do we want to add well designed ciphers with strong
>> evidence behind them that people actually want to use (as opposed to
>> the oft-heard "Yeah, it would be neat if OpenPGP had the new BLAH-256
>> cipher")?  Sure we do.  Or at least, I do.
>
> This doesn't explain Twofish, Blowfish, RIPEMD160, etc., etc.  These  
> are
> well-designed algorithms that very few people use, and they're still
> littering the standard.

Why do Twofish, Blowfish, etc, need to be removed?  Mind you, I don't  
care very much if they are, but we're drifting away from the "what to  
do about new algorithms" question, to the "what do we do with old  
algorithms once their useful life has passed" question.  Who do these  
algorithms hurt?  Remember - they're all optional, all still  
considered strong, and we have a robust system for choosing algorithms  
so that nobody is ever forced to use them.

OpenPGP inherited some algorithms from PGP 5, before there was a  
standard.  All of these algorithms were grandfathered in.  Some others  
were added because people needed them.  If I recall, Twofish was added  
to the spec before AES was finalized.  Twofish has a block size of 128  
bits, which was needed, and at the time, no other ciphers in the  
standard had that block size.

>  I don't think it's at all unreasonable to say
> "Camellia has users supporting it, sure, but before we go about adding
> new algorithms, let's prune out old ones."  The cruft needs to be
> removed, and I don't see the WG addressing the problem.  (I'm on the  
> WG
> mailing list, although I rarely speak up there.)

Adding new algorithms has nothing whatsoever to do with removing old  
ones.  If Camellia is useful and needed, it is useful and needed  
whether (say) Blowfish exists or not.  If someone wants to pursue  
removing Blowfish, go right ahead, but they mustn't expect all forward  
momentum to stop while the removal is discussed.  This is not an  
algorithm swap.

Again, though: we have the means for people to remove the "cruft" on  
their own.  I don't see people doing it.  One user's cruft is another  
user's vital part of the system.

>> I think the 4880 language here is very clear:  you MUST support 3DES
>> (the protocol requires it), you SHOULD support AES and CAST5 (we
>> recommend this, but you're free to disagree, and the protocol will
>> work just fine either way), and you MAY support anything else you
>> like (i.e. completely optional, do what you like).
>
> Clear to you, yes.  Clear to me, yes.  It seems that it is not clear  
> to
> others.  People say "well, CAST5 is in the RFC, so I'll use it," not
> "well, CAST5 isn't a MUST, so I shouldn't depend on it being present."

Who are the "others"?  Who is "people"?  Implementers aren't  
confused.  We all know how to read a standards document.  The RFC  
isn't meant for end users.  If the goal was a user manual, that's a  
different document.

> As simple as we tend to think MUST, MAY, SHOULD, etc., are, Management
> is often not capable of understanding those words.

Management is not the target of a message format document, and we  
cannot redefine how the thousands of RFCs are written just for them.   
You can't make everyone happy with the same document, and trying is  
frequently a fool's errand.

David