I thought it was you who was pointing out earlier the fallacy induced by the key escrow meme (escrowing transient communicatoins keys with governments or companies to recover data stored on frigging disks!) (Actually you applied it just to goverments but the argument extends to companies perfectly).
I can't help but see a difference between enforcing to encrypt to a default key and storing the user's key outright. IMHO, the former entails less potential for abuse.
Tim covered that pretty well. Inconvience is significant. If we can redesign the protocols or backup procedure so that the GAKker must modify software before GAK is even possible we have largely won. If we can accomplish subversion of the OpenPGP standard we may be on to a winner too... if PGP can't implement their beloved GAK functionality without being a non-conforming application. All it takes is for the standard not to accept the pgp5.5 CMR key extension. It really is too new and experimental to include says all. Let's include it as a may says Callas. No thanks says all, we don't want any of it; too new too experimental. If it comes to it, and I figured I could get away with it from a sales perspective I would toss out encrypted email data recovery altogether in preference to implementing GAK for the GAKkers. Implementing GAK for GAKkers has similar immorality to blowing away freedom fighters in foreign countries for sport -- it results in dead freedom fighters, and dead thought criminals (say boo to some governments, and they'll have your head on a platter within hours). The effect is not quite as direct, but it is surely the effect. Even for selfish reasons we don't want GAK for ourselves, and this eventuality is far from impossible in our respective countries.
There are plenty of less GAK compliant things you can do than what they are doing. The anti-GAK design principles help to clarify thought in designing a full spectrum from mildly GAK resistant through to rabidly GAK-hostile. I would hope that PGP (and you lot at C2Net) will crank the setting up to mad dog rabid anti GAK mode with nested obfuscated interpreters interpreting each other interpreting instruction sequences to recover keys. And busting your butts to make your systems ergonomic and slick to the extent that the competitors GAKware products look like dried up turds in comparison. Deployment being probably the most important anti-GAK principle of all!
Amen to the latter. I honestly don't see what PGP could have done better and still achieved deployment in companies that keep copies of all employees keys *today*.
Sure they could. Just simply switching from CMR to CDR: Store encryption key encrypted to a company recovery key on their disk. Or on a floppy in the safe even. No enforced second recipient necessary. Recovery of archived messages possible. Enforced second recipients are worse than straight forward escrow. This kind of thing is better for the reasons Tim listed in his defense of storing the keys in the safe on a floppy as opposed to second recipient. How about forward secrecy? You could make it even less GAK friendly if the keys only lasted for seconds. Then what are you going to do? Send a constant stream of keys to NSA HQ? What if the software tried it's hardest to not allow recovery or access to it's keys (it's hardly likely to given the desire for forward secrecy). So how can that be perverted for GAK? Does PGP investigate these? Hell no! They whinge: ergonomics, too complicated, not possible, you are having a group halucination, you don't understand software design. Yeah, that's right ain't it, we're group hallucinating, and Schneier -- bah they ain't listening to him -- he's just not understanding it right.
And yes, I think what PGP is doing is better than keeping copies of the keys of all employees. Anyway, I now have access to the entire PGP 5.5 system and will subject it to thorough analysis. Methinks many people arecurrently rendering opinions on a design they haven't even seen yet.
You could have a point there. Could you investigate and let us know what it does? important questions which I think are unclear: - does it provide message screening functionality (human reading mail prior to delivery in both directions?) - is pgp5.0 able to generate GAK compliant keys (CMR keys)? - how much control does the SNMP remote configuration provide in restricting user - can you have multiple CMR keys attached to a public key (like one for your company and one for the NSA?)
Certainly, the part of PGP's SMTP agent that prevents you from screwing up by accidentaly sending sensitive email unencrypted stands a good chance of being installed at my site. [Can we all agree that this is a useful feature]? More than once, I failed to encrypt an email that I meant to encrypt.
That part is a truly excellent feature. I do this myself manually, the mechanism I use that I read offline and use linux, so my mail is sitting in /usr/spool/mqueue waiting to go when the connectivity comes up. So I go check the files I care about prior to actually connecting. However that's not the controversial SMTP policy enforcer property. PGP Inc employees described that it rejects mail which is not CAK compliant.
As for C2 and GAK: as Lucky Green, I speak _only_ for myself. And I can therefore say that if my employer was to imlement GAK, I would quit the day I found out about it. It isn't going to happen.
I wasn't suggesting C2 was GAK friendly. I was attempting to suggest that there are things you can do to be even more rabidly GAK-hostile than you already are. Think: monkey wrench GAKkers who might put this product to a work in a GAK setup. Make the product be awkward about the types of functionalities which they will want, make it drag it's feet, make it hide data which it doesn't want transmitted, make it cease to function when servers aren't local (eg. local LAN servers, make them refuse to work for IP#s not on the same sub domain). Be imaginative. PGP are at very best GAK neutral. It doesn't try hard to stop GAKkers deriving use from it. It tries somewhat to prevent users hacking around it's GAK features. It coincidentally (if you believe GAK neutral design philosophy) happens to be pretty useable to the GAKkers. It implements a method for a company which doesn't turn on the GAK feature to advertise that keys are read by company. Yeah nice, but big deal right? Contrast with trying to do all you can to ensure the product can not be used for GAK without a protocol modification, or without software recall, or non-backwards compatible widely fielded international standard rewrite. They do not appear to have tried any of these. 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`