Lucky Green
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