Re: what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))
Adam Back [EMAIL PROTECTED] writes: Back in the days of pgp2.x I used to receive and send a fair proportion of mail encrypted with pgp; these days it is a much lower proportion, and a rather high proportion of those fail. It's not like I'm using old software or failing to try what is reasonable to get messages to work. Even with my fairly complete collection of PGP versions you saw the results. Imagine how much worse it will be between people who do not upgrade frequently or take such defensive strategies. So you say upgrade already. However as I think I have demonstrated, I follow this strategy myself and as you can see it doesn't work either. I've been in a similar situation. Back when I was fighting our government over crypto export controls, it was sometimes necessary to talk to journalists in a manner which didn't give the spooks a week's advance notice about something which they shouldn't have known about until they opened the morning paper. This was in the days of PGP 5.x. Some of the people I was talking with were pretty patient, and often put up with multiple iterations of neither side being able to decrypt the other's messages, but eventually the choice came down to given the opposition advance notice or not having the story published at all, and there's really not much choice there. Now substitute human rights group for journalist and secret police for spooks and you can see why this is a problem. Non-commercial PGP has always been by geeks, for geeks, with features more important than minor considerations like usability. Who cares if there are 146 semi-documented, vaguely-defined command-line options, look at the algorithm choices! If you want to use some obscure hash algorithm which was fasionable for 2 months in 1997, you can, and who cares if it takes you half an hour, the FAQ, the manpage, and an online search to figure out how to encrypt a file? That's why non-commercial crypto will always struggle to find mainstream acceptance. Doing the crypto engine is (relatively) easy, and fun, and there are lots of people willing to help. Doing the UI components is dreary and boring, and no-one is interested because they've just spotted a hash algorithm published in the Journal of the Bratislavian Philological Society in 1978 which they urgently need to add support for. (Although I don't use Windows mailers, I've heard nice things about The Bat, http://www.ritlabs.com/the_bat/features.html, which has built-in PGP support. Apparently at some point Pegasus Mail, http://www.pmail.com, will have built- in PGP and S/MIME support as well). Peter.
what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))
Hi I've trimmed the Cc line a bit as this is now focussing more on GPG and not adding any thing new technically for the excluded set. On Sun, Mar 31, 2002 at 06:08:14PM -0500, David Shaw wrote: The OpenPGP spec handles compatibility issues quite well. The catch, of course, is that PGP 2.x isn't OpenPGP and PGP 5.x isn't OpenPGP. PGP 6 and 7 aren't really OpenPGP either, but they're generally close enough for all practical purposes. I don't see how this is a useful distinction. They are self-evidently not close enough for practical purposes as evidenced by the fragmented user base and ongoing problems you experience if you try using PGP. Back in the days of pgp2.x I used to receive and send a fair proportion of mail encrypted with pgp; these days it is a much lower proportion, and a rather high proportion of those fail. It's not like I'm using old software or failing to try what is reasonable to get messages to work. Even with my fairly complete collection of PGP versions you saw the results. Imagine how much worse it will be between people who do not upgrade frequently or take such defensive strategies. So you say upgrade already. However as I think I have demonstrated, I follow this strategy myself and as you can see it doesn't work either. PGP 7 or GnuPG with the IDEA plugin can handle messages from any version of PGP, OpenPGP or not. I can't speak of PGP 7's behavior in this discussion as it is not available for the operating system I primarily use (linux) as far as I am aware. I doubt it's intentionally hidden, though it's certainly a pain to find. I would characterise the situation as intentionally frustrating attempts to use IDEA. The whole point of the little exercise of stripping out the idea.c, making it a separate dynamically loadable module, tucking it away in a FAQ where you are pointed to lectures about how software and algorithm patents are bad is _specifically, and explicitly_ to discourage use of patented algorithms (and in this case of the idea.c implementation) and to encourage people to do lobby about the patent madness. Campaigning against patent madness is a good cause in itself but not when it gets in the way of privacy to the point that people are sending messages in plaintext. After all what is GPG's primary purpose: is it an email security software package focussing on security, or a platform for promulgating political views. I view the exclusion of idea.c from GPG as basically a security bug of higher severity than for example PGP2.x's manipulable fingerprint, or pgp5.something's (before it got fixed) unsigned ADK bug packet, or the potential buffer overflow in ZLIB. This bug is worse because it reproducibly and frequently causes people to send mail in clear text. The other bugs are by comparison less dangerous, yet they (the two more recent ones) were fixed by NAI, and GPG and other PGP software maintainers with rushed over-night hot fixes. I would suggest this bug would be best fixed in GPG by: a) including IDEA as a default option in GPG -- the ASCOM patent license is really very liberal for non-commercial use, and b) if that goes against the GNU philosophy to the extent that it is worth causing hinderance to hundreds of thousands of users who practically are _going_ to want it they could at least make it a configuration file option and ship it as other crypto libraries such as openSSL do. (I'm not sure how it hurts the anti-patent stance to do this -- gnupg.org is after all _already_ distributing idea.c, just separately). Adam
Re: what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))
On Mon, Apr 01, 2002 at 01:34:35AM +0100, Adam Back wrote: Hi I've trimmed the Cc line a bit as this is now focussing more on GPG and not adding any thing new technically for the excluded set. On Sun, Mar 31, 2002 at 06:08:14PM -0500, David Shaw wrote: The OpenPGP spec handles compatibility issues quite well. The catch, of course, is that PGP 2.x isn't OpenPGP and PGP 5.x isn't OpenPGP. PGP 6 and 7 aren't really OpenPGP either, but they're generally close enough for all practical purposes. I don't see how this is a useful distinction. They are self-evidently not close enough for practical purposes as evidenced by the fragmented user base and ongoing problems you experience if you try using PGP. The fragmented user base is unfortunate. Sometimes I almost wish that PGP 5 had completely broken backwards compatibility with PGP 2 and started clean. At least then there would be no expectation of compatibility. I have spent hours upon hours poring over GnuPG messages, PGP 2 messages, PGP 6 messages and PGP 7 messages in an effort to reach the one magical configuration that just plain *works*. The sad fact is that it is just not possible. This shouldn't be surprising - version n+1 of a computer program adding new features over version n. Version n then doesn't work with a version n+1 message. It's a story as old as computing. OpenPGP fixes it by giving one spec for everyone to follow, and by including a fairly rich syntax of this is what I can handle notations in the keys. It works quite well. Problems tend to arise mostly between the PGP6/PGP7/GnuPG and PGP2 worlds which OpenPGP can't help of course. Again, PGP 6 isn't OpenPGP, and neither is PGP 7 (though it is closer than PGP 6). I'm sure that PGP 8 would have followed OpenPGP even more closely than PGP 7 did, but that doesn't look like it's going to happen now. GnuPG does follow OpenPGP. It also has dozens of tricks and traps to work around PGP behavior where PGP doesn't follow OpenPGP. It even (in GnuPG 1.0.7 (coming soon)) has a pgp2 and pgp6 modes to downgrade messages it generates to what those versions of PGP can handle (it can read messages from any version of course). Since GnuPG can read a message from any version of PGP, and can generate a message for any version of PGP (obviously doing a better job of it the closer that version of PGP follows the OpenPGP spec), and runs on your chosen platform (Linux), I think the real meat of your complaint is in regards to the IDEA plugin: I doubt it's intentionally hidden, though it's certainly a pain to find. I would characterise the situation as intentionally frustrating attempts to use IDEA. The whole point of the little exercise of stripping out the idea.c, making it a separate dynamically loadable module, tucking it away in a FAQ where you are pointed to lectures about how software and algorithm patents are bad is _specifically, and explicitly_ to discourage use of patented algorithms (and in this case of the idea.c implementation) and to encourage people to do lobby about the patent madness. Campaigning against patent madness is a good cause in itself but not when it gets in the way of privacy to the point that people are sending messages in plaintext. After all what is GPG's primary purpose: is it an email security software package focussing on security, or a platform for promulgating political views. I view the exclusion of idea.c from GPG as basically a security bug of higher severity than for example PGP2.x's manipulable fingerprint, or pgp5.something's (before it got fixed) unsigned ADK bug packet, or the potential buffer overflow in ZLIB. This bug is worse because it reproducibly and frequently causes people to send mail in clear text. The other bugs are by comparison less dangerous, yet they (the two more recent ones) were fixed by NAI, and GPG and other PGP software maintainers with rushed over-night hot fixes. I would not call this a bug. A bug is a failure of the system to act as described. It is not a bug if the system annoys a user to the point of not using the system :) Still, yes, the IDEA plugin situation is far from ideal. The bottom line is that GPLed software can't use patented algorithms as it contradicts the GPL. It doesn't matter that the IDEA licence basically allows free non-commercial use - it still contradicts the GPL. I would be quite happy if it became possible to include IDEA (maybe a compile-time option?), but the reality is that IDEA is not required by OpenPGP and every version of PGP from 5 onwards can communicate without it. David -- David Shaw | [EMAIL PROTECTED] | WWW http://www.jabberwocky.com/ +---+ There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. - Jeremy S. Anderson
what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))
Hi I've trimmed the Cc line a bit as this is now focussing more on GPG and not adding any thing new technically for the excluded set. On Sun, Mar 31, 2002 at 06:08:14PM -0500, David Shaw wrote: The OpenPGP spec handles compatibility issues quite well. The catch, of course, is that PGP 2.x isn't OpenPGP and PGP 5.x isn't OpenPGP. PGP 6 and 7 aren't really OpenPGP either, but they're generally close enough for all practical purposes. I don't see how this is a useful distinction. They are self-evidently not close enough for practical purposes as evidenced by the fragmented user base and ongoing problems you experience if you try using PGP. Back in the days of pgp2.x I used to receive and send a fair proportion of mail encrypted with pgp; these days it is a much lower proportion, and a rather high proportion of those fail. It's not like I'm using old software or failing to try what is reasonable to get messages to work. Even with my fairly complete collection of PGP versions you saw the results. Imagine how much worse it will be between people who do not upgrade frequently or take such defensive strategies. So you say upgrade already. However as I think I have demonstrated, I follow this strategy myself and as you can see it doesn't work either. PGP 7 or GnuPG with the IDEA plugin can handle messages from any version of PGP, OpenPGP or not. I can't speak of PGP 7's behavior in this discussion as it is not available for the operating system I primarily use (linux) as far as I am aware. I doubt it's intentionally hidden, though it's certainly a pain to find. I would characterise the situation as intentionally frustrating attempts to use IDEA. The whole point of the little exercise of stripping out the idea.c, making it a separate dynamically loadable module, tucking it away in a FAQ where you are pointed to lectures about how software and algorithm patents are bad is _specifically, and explicitly_ to discourage use of patented algorithms (and in this case of the idea.c implementation) and to encourage people to do lobby about the patent madness. Campaigning against patent madness is a good cause in itself but not when it gets in the way of privacy to the point that people are sending messages in plaintext. After all what is GPG's primary purpose: is it an email security software package focussing on security, or a platform for promulgating political views. I view the exclusion of idea.c from GPG as basically a security bug of higher severity than for example PGP2.x's manipulable fingerprint, or pgp5.something's (before it got fixed) unsigned ADK bug packet, or the potential buffer overflow in ZLIB. This bug is worse because it reproducibly and frequently causes people to send mail in clear text. The other bugs are by comparison less dangerous, yet they (the two more recent ones) were fixed by NAI, and GPG and other PGP software maintainers with rushed over-night hot fixes. I would suggest this bug would be best fixed in GPG by: a) including IDEA as a default option in GPG -- the ASCOM patent license is really very liberal for non-commercial use, and b) if that goes against the GNU philosophy to the extent that it is worth causing hinderance to hundreds of thousands of users who practically are _going_ to want it they could at least make it a configuration file option and ship it as other crypto libraries such as openSSL do. (I'm not sure how it hurts the anti-patent stance to do this -- gnupg.org is after all _already_ distributing idea.c, just separately). Adam
