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