On Jan 23, 2009, at 6:49 PM, Robert J. Hansen wrote:
David Shaw wrote:
This has nothing to do with your preference list. GPG will happily
decrypt messages to any cipher, whether it is in your preference list
or not, as per the spec:
Yes, which sort of demonstrates the point that the preference
mechanism
is just needless complexity. It's a recommendation mechanism without
either enforcement mechanism or standardized semantics. Should the
key
preference list be Borda-counted with the sender's preferences?
Should
the sender use the first sender preference that's in the recipient's
preferences? The last?
The spec is very clear on which preference must be used when it
matters to the protocol, and explicitly disclaims a choice when it
does not matter to the protocol. This gives implementers the
flexibility to do useful things within the hard limits of the
protocol. The semantics are extremely clear, including the places
where the spec dictates that the implementor can follow his desires.
If I allow (say) 3DES, AES, and Camellia, you can't send me anything
that isn't 3DES, AES, or Camellia. If you really really really like
Camellia best, you can send that, even if I like 3DES better. Why?
Because it's *your* message. You're sending it. It's your choice
within the boundaries of what I permit.
Standards are not written by the "Everything not forbidden is
compulsory" ants. OpenPGP lays down the law where it matters, and
steps back when it makes no difference to the security of the protocol.
If I send 3DES to absolutely everyone, then I'm still respecting their
preferences, even if I never bother to read their preferences. That
seems pretty weird to me.
Why weird? Every OpenPGP program supports 3DES (section 9.2). 3DES
is in every preference list (section 13.2). You can pick from any
cipher in the preference list (also 13.2). Thus, you can send 3DES to
everyone without reading the preferences, because you know from the
protocol that you are participating in that every preference list
always contains 3DES. Just in case that wasn't clear, the spec even
mentions this exact case so there can't be any doubt: "Note also that
if an implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation."
If I give you a plate of General Tso's
chicken without even asking you what sorts of food you like, I don't
think it's reasonable for me to say I've taken your preferences into
account.
Computers, lucky us, are not people. Still, if I told you ahead of
time that I would accept General Tso's chicken, a hamburger, or a
piece of pizza, and then asked you to choose, I should be quite
content with General Tso's chicken, even if I really wanted pizza.
Our "protocol" requires that.
This should also explain why I care so little about preference
lists. I
don't care if someone wants to send me AES256, IDEA, 3DES or CAST5
traffic. IMO, they're all perfectly defensible choices. But I care a
lot about the complexity generated by supporting all those ciphers.
I believe this is shortsighted. Simple is good, but too simple is
inflexible. "Make everything as simple as possible, but not
simpler." When MD5 bit the dust, OpenPGP had several algorithms to
switch to (note that PGP 2.x did not). When SHA1 was broken, OpenPGP
could almost shrug that off. I say 'almost' because of the hard-coded
fingerprint issues - which also helps prove my point. If fingerprints
were not hard-wired to SHA-1, the OpenPGP WG would not now be trying
to figure out a new fingerprint scheme.
OpenPGP benefits from the flexibility of being able to use multiple
algorithms. Note that I'm also not saying which algorithms - like
you, I don't actually care all that much which are chosen, but I do
strongly care that the protocol as a whole can support different
algorithms safely and allow for changes without breaking things. This
ability, to me, is necessary complexity. Take the case of TLS 1.1: it
has MD5 and SHA-1 hard-wired throughout the design. Now that it's
time to move away from those hashes, the TLS 1.2 designers had to do a
lot of painful hard work (causing much code complexity and
compatibility problems) to un-wire them. It may be years before TLS
1.2 is really widely supported, and in the meantime TLS users are
going to use MD5 and SHA-1. (There is interesting thread on this
right now on the cryptography mailing list, by the way).
(As
an example, look at what happened with Elgamal signing keys. That bug
would have never been introduced if the GnuPG devs had said "Elgamal
signing keys are rare, they're not required by the spec, and we're not
going to support them.")
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.
Once you accept the idea that protocol algorithm flexibility is a good
thing (if you do), then you realize it doesn't really matter terribly
much which algorithms are in or out of the protocol, or even how many
there are. If you like an algorithm, you use it. If you don't, you
don't. If you want smaller code or simplicity, you simply leave out
whatever you want to leave out. 4880 helpfully states what is
required (DSA, Elgamal, and 3DES, basically). Everything else is
optional - the protocol does not require any of them. The main thing
the protocol requires is that there is a concept of multiple
algorithms and the tools for dealing with that.
What I want is simple: a smaller GnuPG codebase and a smaller OpenPGP
standard. Changing my preference list will not advance either cause
one
iota, so I don't see the point in changing things.
It does tend to argue against what you desire though: if you are
advocating that everyone in the community use a smaller algorithm
list, it does not really help your case when you don't use that
smaller list yourself, "proving" that it is workable in practice.
We had something close to what you describe though: RFC-1991, the old
PGP 2.x protocol. It broke badly when MD5 broke badly (it was already
pretty broken). It wasn't flexible enough to adapt.
If you can think of a way to use the existing mechanisms of RFC4880 to
achieve my goals, I'd love to hear it. Maybe there is some way to
do it
yet and I've just been too dumb to see it -- it's been known to
happen.
Sure, just remove any algorithm you don't want. The protocol in 4880
guarantees that you have the ability to do this:
./configure --disable-blowfish --disable-cast5 --disable-(etc)
I promise you that if you remove an algorithm, any bugs in those
algorithms, be they implementation problems or design flaws, will
never affect you. :)
Despite the joke, I'm really not kidding. I added the --disable-xxx
flags because while I believe strongly that OpenPGP needs the
*ability* to handle multiple ciphers, I also believe just as strongly
that nobody should be forced into an algorithm they don't want used.
Set those flags, and you have a smaller codebase (the code is actually
left out of the build altogether) and smaller standard (you can ignore
any references to those ciphers in the standard).
David
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
