-----BEGIN PGP SIGNED MESSAGE----- In <877686661.25414.193.133.230.33@unicorn.com>, on 10/24/97 at 02:51 AM, mark@unicorn.com said:

shamrock@cypherpunks.to wrote:

...

I have watched this silly debate for some time now. PGP pulled an awsome hack on corporate America, bringing strong crypto to thousands of corporate drones, while Cypherpunks, the crypto elite, seems incapable of reponding with anything other than to engage in frenzied mutual masturbation fueld by GAK fantasies.

This is sad. Very sad.

Lucky, did you actually read anything I wrote, or is this merely another knee-jerk response?

If you can explain the following, then I'll accept that my fears are merely fantasies:

1. How PGP can prevent CMR being converted into GMR; their system builds all the code required to support mandatory encryption to FBI and NSA keys into every copy of PGP.

No their system does not. For what the FBI and NSA want much more needs to be done. Not to mention that *ANY* crypto system can be turned into GAK if the FBI & NSA get congress to pass the laws that they want.

2. Why PGP prefer this option to almost identical systems which do not allow GMR. They don't even seem to be interested in discussing alternatives.

What PGP Inc. did was provide what their *customers* , you know the ones that pay their bills and keep them in business, wanted in a timely fashion with little modification to their current code while circumventing some of the more draconian requests.

These are the important questions we should be asking and noone on the pro-PGP side seems interested in answering them. Why?

They have been answered time and time again, you just have not been interested in listening.

Frankly, this issue seems to be the most important since Clipper, and I'm amazed that so many cypherpunks are so dazzled by PGP's name that they refuse to sit and think these issues through.

If this is such a life and death issue why don't you and some of the other Cypherpunks Philosopher Kings get off your armchair quarterbacking write, test, debug, and *market* your superior system?? Then we can all dance and sing the praises of CP Inc. and what a wonderful thing that they have done?? No? Perhaps because the majority of the "PGP Inc is evil" crowd here couldn't make a buck in the business world if their lives depended on it. I also find it interesting how there is "much weeping gnashing of teeth" over PGP 5.5 , which does nothing that couldn't be done with 2.6, while Netscape, RSA and the S/MIME crowd put weak crypto on every desktop?? Where is the Righteous Indignation?? Where are the cries to burn RSA and Netscape on the stake?? I think sticking the "unwashed masses" with 40bit RC2 a more serious and pressing issue than anything going on with PGP 5.5. Of course the Philosopher Kings are too busy in their PGP feeding frenzy to notice such thing. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNFCNV49Co1n+aLhhAQGtUgP+PejRkW8vx0xTN/QTBLnakHZW6aeuIyH8 Rpsw0yckaZbOyHJnGlXxSCxZrBNM1Aiu0SMdgMmu4X9VBTbZgkJwTJaEpik4jCPa 9nLMLl8OCQMWNtaVN7xJfjyY42TJSjxzXp+eGLPCtOhvcxnu0+CJEu7nZM9jId3j uxPkXfwtNrU= =7Le9 -----END PGP SIGNATURE-----

Lucky Green writes:

On Fri, 24 Oct 1997 mark@unicorn.com wrote:

...

If you can explain the following, then I'll accept that my fears are merely fantasies:

OK, I must be missing something. How can it be more evil if the email isn't automatically sent to the owner of the MK key than if the email is automatically cd'ed?

Uh.. I think you've hit on the center of the problem here. Here's my take on it: CMR is potentially dangerous because it can be abused; therefore make things which are harder to abuse for government communications snooping. pgp2.x is potentially dangerous because it can be abused; therefore make things which are harder to abuse for government communications snooping. I think pgp2.x is potentially dangerous too -- the only difference being that no-one that I know was widely deploying policy enforcers for it. Yes even easy to write code has to be deployed -- deployment is the larger part of the battle, clearly. TIS has been selling GAKware for years, and no-one much is using it, as one example. Passing a law over-night that everyone must downgrade to TIS GAKware is problematic -- people will revolt, even companies who have no political stance, just because of the hassle of it. Interoperability matters. If we can widely deploy software which needs to `unpublished' to deploy GAK, we've built some additional resistance to GAK. (With Luckian outlook, this will be a delay rather than a prevention, but it's still a net good). Standards matter too -- if we widely deployed a Internet mail standard (say OpenPGP:-) which would have to be modified in non-backwards compatible ways to introduce government communications message snooping, we'd have enormous resistance to GAK. This is because it becomes international -- if the US doesn't switch to GAK, then a France which tries will face problems: cut themselves off, or not do it, or attempt to do it, but have it unenforceable even for non-technical users. Now the main point isn't that CMR and policy enforcer is ever so slightly more dangerous than pgp2.x, the point is that pgp5.x is being widely deployed; and that people are switching from pgp2.x to 5.x (especially due to limited backwards compatibility being used to encourage move to non-patented algorithms). Say, for the sake of argument, that OpenPGP adds a MUST or a SHOULD feature to have some kind of forward secrecy. Say this feature gets deployed everywhere. (I'm sure we'll all be 100% behind that one!) Numerous anti-GAK features have been proposed. PFS TLS, which as I've shown can be authenticated via the existing PGP WoT is one way (easy to bolt on to existing PGP SMTP agents -- another weekends hack at most). Providing opportunistic PFS inside the PGP message envelope by sending new keys with messages, which may be used to reply in a forward secret manner, and basing data recovery features on storage recovery where possible are others. Deploy such features. Deploy such standards. Imagine trying to revoke SSL standard to make it non forward secret. (Government recovery of web traffic, yeah). That'd be a tough one, right? I presume that is part of C2's motivation in delploying 128 bit web servers, and 40 <-> 128 bit local proxies to uprate browser security.

...

1. How PGP can prevent CMR being converted into GMR; their system builds all the code required to support mandatory encryption to FBI and NSA keys into every copy of PGP.

Agreed. And so did PGP 2.x and any version of PGP that allows for encryption to multiple keys. Anybody can take the 2.6 source and hardcode in a second recipient key.

This to me doesn't say "give up", it says: make something that is more resistant to being abused by governments. What the deployed base does, and what the standards say is important. What the government in some tin pot dictatorship hacks into pgp2.x hardly matters, if the new standard refuses to talk to it.

The answer is that no PK crypto system can prevent being converted for GAK use.

It just isn't that black and white. Some things are clearly much more resistant than others. Most anything can be subverted by governments, but some things are harder than others.

I read the recently proposed alternatives and fail to see how they would prevent GMR any more than PGP's solution. All I saw were convoluted and frequently hasty designs, many of which lend themselves even more to GAK then what PGP did.

Pick a design, explain why it could lend itself to GAK, help improve design to reduce danger. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0