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. > 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. I don't see how to use preference lists to argue for that transformation in how the implementor community views the standard. > 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. :) This is actually what I do. If someone sends me traffic that's encrypted with an exotic, well, I'll use my system's GnuPG (as opposed to the one living in $HOME/bin) to decrypt it. ... 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. This bit of work history anecdote should not be read as any kind of argument for or against anything. It's just a where-I've-come-from sort of thing. That said, if you ever have the chance to write software for the telephone company, don't. [*] For people on the list who don't remember the state of the RFC from the '99-'00 era, double-width SHA and HAVAL were mentioned in RFC2440. To the best of my knowledge, though, nobody ever actually implemented them. (In the case of double-width SHA, I don't know if the algorithm even existed.) _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
