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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication protocols
- Original Message - From: John Saylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 25, 2002 3:14 PM Subject: authentication protocols I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Depending on your exact requirements, there are many potential options. Let's start with the most basic: The parties securely exchange a verifier. There are many variations at this point, but the basic version is (with details omitted for brevity): A-B: I am A B-A: If you are A then you can decrypt this E(K) and use K as our shared key A decrypts and now both A and B share a one time secret This is generally done using symmetric keys More sophisticated, and scaling much better requires a trust model of some kind. This does however get very tricky. There has to be some verification of the key by a 3rd party (which can typically be the same as one of the first 2 parties). However it is possible to build something usable, as long as on one occasion you can verify the identity of the other party. This type of protocol works approximately as so: B has a verified public key for A A has a verified public key for B A-B: S(I am A, our temporary key is E(K), the current time is T) B verifies signature, and decrypts K, K is now the shared secret There are of course variations where it is E(S(K...)) instead of S(...E(K)...) There are many different variations on this, some patented, some unencumbered, some that are secure down to the use a an ATM-like PIN, some that require larger quantities of secret data, some that take 1 pass from A to B, some that take 10 passes between them, some that have nice provable reductions, some that don't. It all depends on what your needs are. But all of these require some trust model, and initial verification of the key is the problem. Moving over to situations where you are not forced to perform an initial key verification requires a trusted 3rd party, which is what you requested to avoid so I won't introduce them. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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 -
