A question about Camellia
dshaw at jabberwocky.com
Sat Jan 24 18:50:34 CET 2009
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
> 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
> 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,
>> 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
>> key bug happened, it did not take down the rest of the protocol.
>> 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
> 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
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
> ... 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
> 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" ?
More information about the Gnupg-users