Anonymous gives some more good feed back on the PGP GAK argument. A real battle of wits here, anonymous appears to be a pro, probably a PGP employee, anonymous doesn't miss anything (apart from the fact that he has apparently swallowed whole the "communications key recovery" fallacy being spread by the GAKkers). Anonymous writes:
Advocates of the model where software is automatically archived on receipt, either in cleartext or re-encrypted with a corporate key, need to be aware that there are problems with it:
No notification to sender about the policy.
[..] People should know if their mail is going to be automatically saved in the clear to a company archive. The best way to make sure of that is to have the sender be the one to do it, or not.
Hmm, you've turned that argument on it's head there, and come up with an interesting counter point. I'm not sure it's that valuable a distinction though, because you can't enforce it either way. You really have no idea what the recipients software is doing, nor who the recipient is printing out and showing your email to. I think that the best that can be hoped for is that it is considered fair play, and a convention that businesses are encouraged to adopt, that second reader policy, and storage policy is flagged. Following from your concerns it would seem we currently have 3 possible "how I treat email" flags: - email is readable by company - email is being archived for company records - email is being archived in the clear - email is discarded after reading Interestingly pgp 2.x has an option to partially suggest that last one, a kind of "don't save in clear" request (from pgp.hlp in pgp263i): Use -m to force display of plaintext only (no output file) I know one person who used to regularly send me stuff encrypted this way -- it used to cause my mail client to barf (emacs RMAIL & mailcrypt.el) because it couldn't cope with this, so I had to manually read it with the command line pgp, which would insist on displaying it to you with it's pager, and not storing it to file. Quite a nice privacy touch. Anyway you used your point to argue that:
The best way to make sure of that is to have the sender be the one to do it, or not.
which I take to mean that you are using that to argue that the PGP GAKware enforcement feature is a good idea. I strongly disagree because a) communications keys should be shorter lived than storage keys, b) the way the PGP GAKware enforcement and flags are implemented is literally an full GAK implementation, c) that it is less secure to put extra doors into what should be for security reasons short lived keys.
No way to prevent third-party access.
With the corporate message recovery feature, the sender has the option of simply ignoring the recovery key and sending it encrypted just to the recipient. Some corporations won't let it through, others will.
True.
Some companies will want mail to be made recoverable by default, while still allowing an escape clause for personal mail and special purposes (like for "sensitive" mail which needs protection against subpoena and discovery). They can use the "optional" CMR mode. Again, senders are always notified as to which mode is being used by a given company,
Notifying senders of the archiving and access policy is good and to be encouraged, however it never proves anything about what is actually happening to your email, nor can it.
and senders can be confident that if they don't use the third-party key, no access will be possible.
I don't think this is true. They will have no more proof that this is the case than they will have with the storage recovery key solution. Consider: the company could just as easily take copies of the email after the user decrypts it with CMR. The user may have an _expectation_ that there is no third party access, but they can only hope that their expectation tallies with the truth of the situation, and this is the case for either my storage recovery solution, or PGP's CMR solution. So there are no meaningful differences from this angle. There are two major and definately meaningful differences between corporate storage recovery (CSR) and CMR: - CMR is a fully functional GAK implementation CSR is not This is directly analogous to the difference between GAK and data recovery, and was the reason the cypherpunks that Jon Callas observed chanting "key recovery bad data recovery good" where chanting. The irony was Jon didn't realise that he was falling for the GAKker promulgated fallacy that these cypherpunks were chanting against, and yet he was using the same chant in his arguments not realising what it meant. - CSR is more secure because: a) it allows shorter lived communications keys b) because it leaves no long term doors into communications, whereas CMR leaves two doors into communications
With automatic encryption and archival on receipt, all mail will be archived, and senders have no notice and no guarantee that stated policies will be followed.
You have no guarantees either way. You can implement any functionality for storage, escrow, and message snooping with varying loose degrees of tamper resistance into either CSR or CMR, using a combination of storage key escrow (CSR) and Mail client enforcement or GAKware (CMR) with the session key going over the wire encrypted to the GAK master key. As I said above, the best we can do is to encourage truth in advertising about storage policy and number of people who can read; and to provide flags to express these meanings within the OpenPGP standard.
No escape via super-encryption.
Even if the company is mandating a recovery key and filtering out messages which aren't encrypted to it, the sender still has the option to super-encrypt with the recipient key alone, before sending the message encrypted to the corporate recovery key. This ensures that only the recipient's personal key can read the message. With software which automatically saves the cleartext of the message, once the user reads the data it is available to the corporation via the snoopware.
Wew. Hadn't thought of it that way. Well you could choose to implement it that way, or you chose not to at your option. It hadn't even entered my head to implement it that way! and I would strongly argue against so doing. (I am starting to appreciate how PGP people must feel about my criticisms of their features; never-the-less, I am confident that my argument is correct, and it is they who have allowed themselves to be blinded by the GAKkers fallacy of escrowing communications keys (the chanting cypherpunks mantra explained above)). However, and this shows how you can still trivially hack around it, you could super encrypt to a key which wasn't storage escrowed. I also have said things about "official email" and "unofficial email" which I considered companies should be encouraged to provide for their employees, and there is a case to be made for this as argued by Tim May and Bill Frantz recently, which is that it is probably not in the companies interests. I originally started out thinking that companies didn't as such need much in the way of access to old email messages, or that they could store them in the clear and encrypt the whole disk with recoverable storage keys. However some tenacious people (you?) started arguing that it would be a security breach to store email in the clear after having encrypted it for communications. There is also the case to consider of the PGP Inc mail client which does not integrate disk storage functionality. Therefore I was worked out a sample architecture demonstrating that you could archive email in encrytped form if you wanted to acheive this without needing GAK compliant architectures such as CMR. I would also defend myself from the above slur that I was trying extra hard to ensure that there is no escape from super encryption. I have lots of ammunition, don't worry :-) The reason that I am trying to demonstrate that you can enforce any of this at all, is that some of the GAKware proponents on the list (anonymous and not) argue that it is necessary not just to have access to communications keys for data recovery purposes to ensure data availability (there's that recurring fallacy again), but also that it should be possible for the company to snoop on the user without the user being able to avoid this. If you are at all worried that your GAKware CMR system doesn't quite meet up with the flexibility of my system in allowing you to get all little brotherish and enforce things, well I can make a suggestion as to how to increase the enforcement rate of your GAKware system. Do a web search on "Binding Cryptography" by a guy called Bert-Jaap Koops, and a couple of co-authors (I think another of the authors is the main author, but I don't remember their names right now.) I was particularly disappointed at the time with Bert-Jaap for allowing his name to be put on a paper describing a technology which has only one purpose: GAK enforcement, and expressed this to him. However I suppose technology is neutral -- it is what you use it for that is the problem, probably it could have some other uses. So, y'all PGP Inc GAK lovers will love what this allows: it allows you to enforce at your GAKware big brotherish SMTP policy enforcer app on the inbound direction that not only is the El Gamal key with the correct key-id there in the GAK master key second recipient, but that the same session key is in use inside of the users PKE packet. Not that I'm suggesting that you do that or anything, I merely draw it to your attention to demonstrate my point that either of the systems can be implemented in varying amounts little brotherishness, but that the over-riding point still remains that CMR is a fully functional GAK system where-as CSR is functionally useless for GAKkers because they want to read your communications, not what is stored on your disk. This is because the GAKkers will have to break in to your building to get your disk, this is not nearly enough fun for the Feds, because they kind of fancied having push button remote key word scans of the entire world communications. (Remember the meme the chanting cypherpunks were trying to promulgate as described above: governments want access to comms keys, businesses want access to storage keys. This cypherpunks meme is absolutely central to the whole argument).
Facilitates GAK!
Suppose this solution is adopted, and software is developed which automatically re-encrypts received email and sends it to a secure archive. It's robust and works with a wide variety of email packages. Now the government could simply mandate this to be used for all mail reading software.
You are indeed an observant anonymous person! I'm obviously dealing with an extremely bright person, even if he seems to have swallowed the inherent fallacy of the communications "key recovery" meme which the GAKkers are promulgating. I too fretted over this possibility. And this is why I tried to avoid the idea that you would have a central company archive of stored encrypted email. I couldn't work out a way to ensure that the communications which were intended to occur inside the corporate LAN could be prevented from being abused to implement GAK, a problem that you so observantly spotted also. Aside from being awkward and implementing it with screwy transfer protocols so that it was all non-standard, it seems inherently difficult to avoid. So firstly I switched to contenting myself with satisfying what PGP Inc claimed the user requirements for CMR where. To me this meant that centralised backup would have to be avoided to avoid GAK compliance. You could argue independently that not doing this is far less little brotherish anyway. Also that you can enforce to some reasonable degree storage on the local machine, to give second access to the users mail folder, which is better than having a central snoopware HQ, which can then be perverted to become NSA GAKware HQ. (Granted the employee could purposely trash the disk by taking it out and breaking it -- but you'd still have backups from the last backup point -- and we're not after 100% success rate because there are other easier ways to bypass the system). Jon Callas claimed the main company requirement for data recovery was for companies to be able to retain data availability. So if we take him at face value, that presumably means that companies don't especially want high assurance snoop functionality to read email where recipients refuse to decrypt it, or go to extra efforts like super-encryption. Jon Callas and other PGP employees also argued as a plus point for the CMR design that it was easy to bypass. This suggested that users could deny company data availability in a number of ways, and that PGP employees wouldn't be losing sleep over that. Well CSR achieves all that. You can hack it in various basically analogous ways that you can hack CMR. Now, as I describe above, the reason that I started talking about tamper proof clients was to demonstrate to those who complained of loss of company ability to snoop in the face of a company employee hostile to the snooping. If you don't like that (and I sure as fuck don't), well don't build the little brotherism in either. But, if you do want to have some kind of mildly enforceable corporate snoopware well you can do it with reencryption to an escrowed storage key or to a key recovery storage key. For people who want to stop employees beyond that I think it is reasonable to say that this is disproportionate effort spent on the problem given other physical avenues for company information leaks. If a company is that way inclined that could say that attempts to subvert the snoopware was a sackable offense. (Again not that I'm arguing we should be encouraging companies to do any of these things, but rather than in proposing the CSR method as a non GAK compliant replacemnt for CMR, I am being challenged to demonstrate it can do everything that CSR can do with similar levels of enforceability).
The secure archive would be a remote archive maintained by the FBI to protect public safety. All plaintext would be sent there, encrypted by the FBI key. The business software would already support this. This is GAKware! Unlike with a CMR system, the sender would have no way to prevent access.
He could prevent as I argued above; also you could build more secure and similarly hard to bypass GAKware (CMRware) with Binding Cryptography and a restriction to El Gamal keys. Anway I would strongly argue against fielding a system which worked in this way, for the exact same reasons that I am arguing against PGP Inc's fielding of the CMR system: because as you so rightly and observantly point out it is GAK. (I am not noticing you say much about CMR being GAK ... perhaps you actually acknowledge it is GAK, but are trying (and I think failing) to show that CSR is GAK too. Well no dice, I think CSR allows non GAK compliant functionality with a large degree of flexibility. CMR on the other hand just _is_ GAKware. If you remember the KRAP (Key Recovery Alliance Program) and have the documents handy I am sure that if you go down the checklist that you will find that pgp5.5 matches just about all of the hotly contested NSA given requirments.
Can't handle forgotten passphrases.
People forget passphrases all the time. With re-encryption on receipt, there is no way to recover gracefully from this error. All the incoming encrypted data is lost until you can notify everyone who has sent mail to resend it, and get your new key out to all of them. These may be purchase orders, sales leads and other important documents which represent lost business if they can't be recovered. This is going to invite people to use poor security practices like writing down passphrases or choosing ones which are easy to guess. Worse, it...
Lets think this through. You have 3 keys. - storage keys - signature keys - communications keys You can escrow storage keys if you want -- this provides data availability. As an alternate and approximately equivalent mechanism you can use storage key recovery (with a second storage recipient). Signature keys we shouldn't have any arguments about I think because y'all presumably agree that the user should be the only hodler of those to prevent third parties forging his signature. Communications keys, for security, and non-GAK compliant design reasons you also should not escrow. I think that your complaint is the same as that raised by someone else, that is if some emails come in and in the mean time the employee forgets his passphrase, you lose the emails because you can't recover the communications key, because it is treated like signature keys; no escrow, no backup. This is a valid complaint. However as a fob to the significance of this I can offer: - if the email is important value "official communications" as you suggest, it might be an idea for the sender to archive them anyway in case they disappear down a blackhole in transit, or it will be independently likely that the important company document / figures / source code will be stored on the senders disk somewhere. It's the only down side I can see for the system, which allows you to avoid GAK compliancy. It also has a number of quite major security advantages which I discussed with William Geiger in the thread on DH forward secrecy in email.
Invites key escrow.
In order to prevent this problem, employees may be forced to share their secret keys with corporate management.
You could do this as a solution. However it has GAK problems, and has as you say Clipper overtones, using the same master access method. However you could also view it this way: you will likely be encrypting the private parts of the communications key with the same passphrase as the private parts of the signature key. If the user forgets their signature passphrase you'll have to issue them with a new set of certificates for their newly generated signature key. This is also inconvenient, but you live with it because of the over-riding principle that signature keys should only be held by individuals. With communications keys the main reason not to escrow them is that doing so builds a GAK system. Thus is harder to argue that these restrictions are inherently necessary unless you want to avoid GAK so much that you are willing to live with this weakness. I'll think on this part to see if I can find some way to tune down the significance of this type of data loss. Do you have any ideas? One which comes to mind is smart cards for key tokens. Harder to forget. Still you _can_ lose them. There is however a separate danger with smart cards, they are kind of a form of escrow themselves if they are not tamper-proof enough because someone with resources may be able to recover the keys from them. Smart cards are however very convenient for key storage.
Software will be written to facilitate this process. Crypto companies are already doing this. Nortel Entrust allows key generation by management, where employees are given the keys and management keeps a copy. Shades of Clipper! This also fails the notification requirement. Don't believe me? Take a look at this description of the Nortel Entrust product:
Yeah I believe you. Some folks don't give a shit about privacy, nor about GAK. The $ is all that counts to them. Selling their mother for a bit of change wouldn't cause them a second thought.
No system is ideal.
Before pushing this re-encryption model as a panacea, think about the implications. No system which provides automatic access to business data is going to be privacy friendly. Any such system can be perverted into supporting GAK. Load it up with all the disclaimers you like, but if you advocate software which contains key escrow and which automatically provides cleartext to third parties, you are not advocating software which protects privacy. Be prepared to be called an advocate of GAK next time you push for software which automatically archives cleartext, because if it can save it for business, it can save it for government.
The difference is still centered around the central fallacy that the GAKkers are promulgating that the government should be allowed to have access to all of your communication keys to allow the company to protect data availibility. The problem is that your disk is not stored in those communications, so having the communications key back from the government key recovery infrastructure does nothing to help you recover your disk data in event of a disk crash. In addition my simple observations derived from this are that well: - if government is so damn keen on gaining access to communications keys, we'd better make damn sure we have no data on disk encrypted with communications keys! - if government is so damn keen on encouraging companies to build GAK products (clipper, tessera, KRAP (Key Recovery Alliance Program) Public Key Infrastructure ("CAs" with copies of communications keys, as if you want them backed up)), well I'm going to do my damnest to make sure that I don't write the software. If PGP Inc chooses not to write a GAK compliant product, and the PGP standard is successful, well then we have done all we can to frustrate government GAK plans Given those observations, lets take a look at this claim:
No system is ideal.
Before pushing this re-encryption model as a panacea, think about the implications.
I'm trying. Your feed back is helping to explore the limitations and flexibilites of CSR as new scenarios are explored.
No system which provides automatic access to business data is going to be privacy friendly.
Well it's a little brotherish sort of activity perhaps, but some argue that companies have property rights which you could use to conclude that if they are paying for your time, and they own the machines, and the networking facilities, that perhaps this isn't so unreasonable. Provided you stick to data stored on disks you minimise your problems of being accuesed of GAK.
Any such system can be perverted into supporting GAK.
I have given you a CSR architecture which is non GAK compliant. Your task is to deploy this as widely as you can. Then with 80% of companies using non GAK compliant software, the GAKkers are going to be struggling. The other scenario, PGP Inc's CMR, is already GAK enabled. It provides a smooth migration path to GAK. With 80% of companies using that type of GAK compliant software we're screwed. PGP will be the guilty party.
Load it up with all the disclaimers you like, but if you advocate software which contains key escrow and which automatically provides cleartext to third parties, you are not advocating software which protects privacy.
There can be legitimate reasons for restrictions on privacy within companies where this is required to ensure data availability. The main points about this are that a) you recommend the policy of informing users (ensuring that they know that the data on this disk is backed up, that this email folder is backed up etc.) b) that PGP doesn't use the excuse that a GAK system _could_ be built by perverting CSR as an excuse to fields something which is unavoidably a GAK compliant system: CMR. With CSR you as implementer and to a certain extent standards setter have the power to do something about having a non-GAK compliant installed software base. With CMR you have no choice but to implement and field GAK compliant software.
Be prepared to be called an advocate of GAK next time you push for software which automatically archives cleartext, because if it can save it for business, it can save it for government.
I don't think that is really fair. My motives for exploring the functionalities is driven by other peoples user requirements which they are thrusting on me with the challenge that I show that they can be met with CSR. I have almost completely been able to show that this can be done for the things which have been thrust at me. This in no way indicates that I _like_, or approve of the little brotherish, or snoopy things people are challenging me to show can be implemented with CSR. But what I am certain of is that you _can_ build a non-GAK compliant system with CSR, which can have just about any functionality you care to add (snooping, weakly enforced email archiving to recoverable keys, separate "official" and "unofficial" email boxes, flexible storage key recovery architecture). I am also certain that CMR as implemented by PGP is a fully functioning ready to roll GAK compliant system. Lets try a different tack: I'll issue _you_ a challenge: can you modfiy the CMR proposal so that it still achieves stored email data recovery and so that it is no longer GAK compliant. I don't think you can do it. I'll be happy to be proven wrong. I think you'll find as you try to work your way around away from GAK compliance it that you will end up with something which _is_ CSR. Well? (Thanks for the long debate... I hope it has been useful). 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`