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
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
