A question about Camellia

[Robert J. Hansen]

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?

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.  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.

> You seem to be advocating that the community sweep away the ciphers 
> you don't favor so that nobody can use them.

I take objection to the "so that."  That ascribes to me motives I don't
possess.  If someone waved a magic wand and said, "okay, OpenPGP now
uses only AES, RSA and WHIRLPOOL," I'd consider it to be an improvement,
despite the fact the ciphers you're alleging I favor would now be
removed from the spec.  My goal is simplicity -- which algorithm suite
is used is really an afterthought.

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.  (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.")

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.

On the other hand, if there's a community consensus that RFC4880 has
grown too complex and needs to get pruned, then I think that consensus
could turn into a smaller spec, a smaller codebase, and more trust.

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.