Lucky Green <shamrock@cypherpunks.to> writes:
On Tue, 14 Oct 1997, Tim May wrote:
(Disaster planning, for "what if Alice gets hit by a truck?" scenarios, are of course handled by having Alice lock up her private keys in her safe, or perhaps her department manager's safe, whatever. This is a dangerous security flaw, if the key is released, but has the advantage that it's a fairly conventional recovery approach, and is not built into the cryptosystem itself.
Tim, The system above you are proposing is [C,G]AK, plain and simple. This is what some companies are doing already. And it is a Bad Thing.
It is GAK pervertable, but it is much more resistant to GAK perversion than PGP Inc's CMR system. I think Tim can reason pretty well without cribbing from the anti-GAK principles, but that he could present marginally more GAK-hostile systems by using the anti-GAK principles. (Or perhaps he would figure them out anyway but figures them to be too complex... my only real claim is that by working to these principles that it helps clarfiy what you are trying to defend against, and trying to avoid in your systems). The reason that you are right that what Tim suggests is GAK pervertable is that it partly violates one of the anti-GAK design principles I have been trying to hone. It violates the principle that recovery information should not be communicated (via sneaker net on a floppy to the company safe). It does however obey the corollary that: if you figure you must move recovery data, you should at least make it inconvenient, avoid electronic communicated recovery data, and generally require the recovery data to be as localised as possible. (Also the principles state that you should use forward secret comms keys, but I think that might be pushing it for sneaker net between machines and a laptop in the safe for ergonomics reasons :-) Here is how use of the anti-GAK design principles can help to provide a more GAK hostile system: It is better to use recovery rather than escrow. (Encryption of Alice's private key with a companies recovery key). This allows you then to store the recovery information more locally to the data, closest possible locality to data being another anti-GAK design principle. Now how is this harder than GAK? Heh well you need to use your imagination and try to make a system designed to fuck with the GAKkers minds at this point. Remember not only do you design the system to not communicate the key automatically, you try your best to prevent it being removed from the system. Here's a few ideas: You store the recovery info on the users disk only, but you do your damnest to obfuscate it. Encrypt it with keys hidden in the executable, obfuscate the code to hell and back, and don't provide source for that module. (Obfuscation tricks like interpreter of encrypted instruction streams ought to take a little bit of unwinding). You also hide the recovery data inside the keyrings, and obfuscate them to hell and back around the file system in slack space etc. This is to make it harder to copy to a floppy. So now the GAKkers can still get your recovery info, because they could theoretically unwind that problem. But it is sure a lot harder than requiring every one to email them a copy of the key they just put on a disk. The software doesn't give you any help obtaining your key in a mailable form, or in a form to stick on a floppy either. In fact it does it's damnest to prevent it. This is the kind of monkey-wrenching PGP should be investigating, rather than investing time in designing `elegant' GAK implementations. Combine with forward secrecy with as quick update time as you can manage without interfering with ergonomics issues, and the GAKkers have got to come back every 5 minutes, and grab a copy of your entire disk, or reverse engineer the obfuscation, to grab the next obfuscated key.
[Sidetrack: which is of course why PGP had to find another solution to present to those customers already using GAK. IMHO, and I can't help but be a bit surprised that I find myself in the minority on this issue, at least as far as the list is concerned. What PGP did was _elegant_.]
Wow, Lucky! I usually consider you to be spot on most such things, but I think you failed to hit the bulls-eye there; in fact I think you missed the dartboard entirely! 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). The only way that it's elegant is that it is an elegant fully ready to roll GAK implementation. (Notice Bruce Schneier's forward of a case of a GAKker already starting to crow about the demonstration of GAKware feasibility in PGP). 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! 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`