[I've moved this thread to cypherpunks, it was on cryptography, and Perry (cryptography moderator) just killed the thread. Some of the participants may not be on cpunks, so keep them on the cc if you want them to see your replies] Marc Horowitz <marc@cygnus.com> writes:

...

...

...

What makes you think that all critical email is on disk in the clear?

Nothing: it could be on disk encrypted. eg. Encrypted files encrypted with storage keys, or encrypted partition encrypted with storage key, or encrypted sent or received email encrypted with storage key.

Well, if it's encrypted on disk, then "you read the disk" doesn't get you very far. You need to be able to decrypt the information on the disk.

Of course you do. Lets say you are using Peter Gutmanns encrypted filesystem setup. So, if you figure the info on the disk is important, you give a copy of the key to the company lawyer, put it in the fire proof safe, secret split it, whatever tickles your fancy. The advantage of this is that the email software it is no use to the GAKkers, because it doesn't have mildly enforced extra crypto recipients, and it doesn't get the business community used to the idea of shipping email around with extra doors into it. PGP Inc's pgp5.5 could be used by the government to weedle their way into mandatory key escrow. Say that they start requiring companies to use this software, then when lots of companies start using it, they start asking companies for a copy of the company master key. Bingo key escrow, courtesy of PGP Inc. Next they "encourage" ISPs to use it also.

...

...

The way to do it is as described above. Archive the email, encrypt it to a starage key. Build that functionality into the MUA if you fancy. But _don't_ give extra access to keys used for communications only.

There is no extra access to communication keys.

There is so! His mail said that there was a policy flag in the public key, and an additional public key for the corporate back door. That policy flag effectively said this key has attached to it a request that you encrypt to this extra crypto recipient. In some cases an additional flag will be set which says "if you do not comply with the request to encrypt to the extra crypto recipient, the recipient will not see the mail". PGP Inc's method of enforcing this is an SMTP policy enforcer which bounces mail without the extra crypto recipient. There, that is an extra access to the communication (via an extra route to accessing the session key). Uhhh, I think I just realised why we are talking at cross purposes... you meant extra access to the recipients private key. I consider this an artificial straw man, erected by Jon. Sure it's an independently dumb idea to have lots of people sharing private keys. But the system is still GAK friendly. And it does allow extra parties access to the message. The worry is that government becomes that second party. Do you really care about the details of mandatory GAK, when and if it comes in. Do you care whether the government has a copy of your private encryption key, or whether the system is setup with un-bypassable second crypto recipient of the USG/NSA etc. Can't see that it makes much difference at that point. Both methods can be bypassed theoretically anyway, by super encrypting or any other subliminal channels kicking around in the protocols. So I can't see that arguments about how easy they are to bypass hold much water. Frisbeeing a disk out the window is far easier a way to bypass anyway. Or just blabbing.

...

...

Hint: you will note that Freeh and friends aren't interested in storage keys. You can see why the above systems is less GAK friendly right?

Freeh wants storage keys, too. He wants *all* the keys.

Yeah he probably does. But he wants your communications keys a lot more. You know why that is? Because he has your communications because you're broadcasting them across the Internet. He'd like to read them. However he doesn't have your disk, and he'd have to break into your offices to get it, or issue you with a supeona or whatever. I'm sure he'd love to read your disk too, but your disk isn't sitting on an NFS mount over the internet. (Is it!?) Fortunately, the internet couldn't handle the strain, otherwise you might see calls for you to rent your disk space of government disk farms, and the government would then be very interested in demanding a copy of your storage keys. So, if even if we use corporate key backup for storage keys, this is still more along the lines of the status quo. They want your documents, they've gotta come and get them. What we'all are getting worked up about here is that Freeh and friends want to be able to key word search our damn communications on fishing expeditions.

Email is a funny thing. It's sort of storage, and sort of communications. I can understand wanting to recover it from a communications aspect. They don't call SMTP "store-and-forward" for nothing.

There is no information in the body of the message which is required for it to get to it's destination. All you need is the SMTP headers. You clearly can't end-to-end encrypt the communications routing information. (You could layer it though, like perhaps remailers, with each hop only knowing what it needs to know to do it's job; however at that point you can run into problems: you can't bounce back a delivery failure part way along the route.)

You'll notice that if I delete the messages after receiving it, it can't be recovered. If I don't, it can. Sound like storage to me.

So? The point is that you shouldn't be mixing key purposes. Communications private keys should be used to protect communication and shouldn't be given to anyone else, even your company. Storage keys might be sensible things to backup within the company in case of accidental death. Actually I disagree with what you said: you said "if I delete the message after receiving it, it can't be recovered", it might easily be recovered in lots of ways: 1. feds have tap on your line, feds rubber hose your long term private key out of you 2. your sender has kept a copy in the clear 3. your sender has kept a copy encrypted with a poor passphrase which the feds guess/or rubber hose from him 4. your sender used encrypt-to-self, and has poor passphrase/is passphrase rubber hosed 5. your sender kept a copy which still had you as a crypto recipient (as well as himself with encrypt-to-self), and the feds arrive at your door anyway. Point is, as long as you've got the private keys, it is potentially stored, courtesy of your favourite TLA. This is why you should use forward secrecy, or at least mimic it, by having a long term signature key, and generating a new public key for encryption every week/month, and revoking and destroying the old one.

...

...

I figure it's not that major a deal. But for those that want it, the most secure, simultaneously least GAK friendly way to do it is to archive and encrypt with separate storage keys.

This is *exactly* what PGP does: it encrypts with the recipient key, and the recovery key.

Yes, it does, and that is GAK friendly. But that is not what I described above. The difference between what I describe above (quoted a few lines up), and what PGP is doing is that PGP's messages are sent across the internet encrypted to the "recovery key". This is GAK friendly because it is easy to implement GAK with it, you just make that "recovery key" the NSA's "recovery key" (or to avoid newspeak terms perhaps that should be government backdoor master key). Then they coerce ISPs and corporates to include a PGP SMTP policy enforcer which insists on all email having a second crypto recipient of the NSA's backdoor master key. The system is a beautiful GAK system, everything you need for a fully working GAK system is right there on sale by PGP Inc. With what I described, GAK is not possible. What I described is: the MUA archives sent email, and archives received email (after decryption) with none of this process leaking outside the corporate lan (that is it may involve communication inside the LAN). The archives can be encrypted, and you can have a corporate master key with access to these archives. But none of this goes over the Internet.

At this point, I'm not sure if we disagree or not.

I'm not sure either, please let me know if I've explained myself this time! I'm worried that the hard time I'm having getting people to grok that escrowing comms keys is a bad idea if you're opposed to mandatory GAK is indicative of the success of the memes being spread by Freeh's crowd. PGP Inc are especially worrying, as they are in a position to influence the balance of whether we get GAK or not, and they appear to be helping GAK out somewhat. Whether this is complicit or whether they don't see that the fact they've implemented a fairly feasible GAK system as that significant in the argument, I'm not sure. However, I think the argument it is relatively straight-forward: companies care about backup of their data. They don't care about backup of their communications. So why backup communications keys? And why include the backup packet in the communication itself? For those companies who have been persuaded that they ought to read email received and email sent, you can implement this without weakening comms security as PGP have done with pgp5.5 for business which is to have a second crypto recipient for backup/backdoor being sent with the message over the internet. All you do for backup or company backdoor is to build in whatever storage, and encrypted archiving functions you wish into the MUA, or internal mail system. That is GAK unfriendly. If PGP Inc is still GAK unfriendly, and hasn't sold out to government, it should be doing something with similar properties to those I described above: not having backdoor second recipient access to traffic. What they have done is implemented a fully functional GAK system. (I get the feeling that sooner or later we're going to get a PRZ penned company position statement. I hope they get it right. I encourage them to re-think.) 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`