A question about Camellia

[David Shaw]

On Jan 24, 2009, at 12:44 AM, Robert J. Hansen wrote:

> David Shaw wrote:
>> OpenPGP benefits from the flexibility of being able to use multiple
>> algorithms.
>
> The ability to use multiple algorithms is independent of how many
> algorithms are in the spec and in each implementation.  Algorithm
> agility is a great idea and I think protocols ought be designed with  
> it
> in mind; but at the same time I think protocols ought to focus on a
> minimal set of algorithms.
>
> An extension mechanism is a great idea.  I don't think that should be
> carte blanche for a spec throwing the kitchen sink into the RFC,  
> though.
>
>> I think this is actually a good example for my point as well (I  
>> love an
>> example which points out multiple things): Note when the Elgamal  
>> signing
>> key bug happened, it did not take down the rest of the protocol.   
>> People
>> with RSA or DSA signing keys kept right on chugging.
>
> Yes.  We're in total agreement that algorithm agility is a good idea.

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?

Camellia is a good example here.  It does not really bring something  
new to OpenPGP in terms of security.  Sure, Camellia is believed to be  
strong, and some studies have shown it to be strong.  But we don't  
really *need* that - we have other ciphers that are (arm-wave here)  
roughly as strong.  So why add it?  Because it brings something  
helpful to the protocol as a whole - it means OpenPGP can be used in  
certain environments in Japan that mandate Camellia.  More people  
using OpenPGP is good.  That helps the community.

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.

>> It does tend to argue against what you desire though: if you are
>> advocating that everyone in the community use a smaller algorithm  
>> list,
>
> Looking over RFC4880, 3DES is the only MUST symmetric cipher, but it
> makes mention of Twofish, Blowfish, CAST, IDEA and AES.
>
> Better, in my mind, to reduce this to 3DES (or AES, take your pick,
> algorithm agnosticism and all).  Move the others to an appendix.  Note
> them for history and interoperability with old versions, but encourage
> implementors to not use old algorithms for new traffic unless there  
> is a
> compelling reason not to.

So if I understand, the change you advocate is to move the optional  
algorithms to an appendix?  They're already tagged as optional (they  
can't, after all, be made *more* optional).   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).

Remember that 4880 is not a guide to the coder, nor is it intended to  
be used to favor or un-favor particular ciphers beyond what is  
necessary for interoperability.  It is a mainly message format  
document (note the title of 4880 is in fact "The OpenPGP Message  
Format").  While there have been various suggestions for a "OpenPGP  
Best Practices" sort of RFC, nobody has of yet stepped up to write  
one.  I suspect this is due to the currently limited community of  
people developing OpenPGP software, so it is not clear who the  
audience of such an RFC would be.

In the meantime, though, we have a message format.  There is a section  
for ciphers, and all the ciphers are in that section.  Having two  
sections for ciphers would just makes people scroll around when  
reading it.

My understanding is that you do not favor Camellia in OpenPGP (which  
is what started this thread).  I don't quite see how to reconcile that  
with your "algorithm appendix" comment.  After all, Camellia is in its  
whole own draft.  You can't be more detached from the main RFC 4880  
than that.

> ... I'm motivated, to some degree, by my own frustrations in
> implementing RFC2440 for a telco back in '99.  My implementation was
> simple: 3DES, SHA1, DSA/ELG, no compression, no MDC, no nothing, but  
> it
> was -- as far as I could tell; it's been ten years, please  
> understand my
> memory isn't perfect -- standards-conformant.  I could send traffic to
> PGP and GnuPG, PGP and GnuPG could, with the proper settings, send
> traffic to me.  Success.
>
> It was not enough of a success for Management.  They insisted on
> supporting IDEA, CAST, MD5, RIPEMD160, etc. -- when I got knocked down
> on a performance review because I hadn't yet implemented double-width
> SHA or HAVAL, I knew they were viewing each and every algorithm as a
> checkbox. [*]
>
> This is obviously far, far more a failing of management than a failing
> of the spec.  That said, I think the spec contributes to this kind of
> misreading and misunderstanding.

How?  You don't think they'd have just asked for all of the algorithms  
in "Appendix A" rather than "Section 9.2" ?

David