On Wed, 1 Nov 2000, David Honig wrote:
Although its hazardous if done wrong [cf recent PGP problems], is tarnished by the Fedz/Denning/etc, and might have no use in a personal privacy tool (your diary dies with you), isn't it too dogmatic to rule out key escrow for tools intended for use by groups?
Are there equivalent methods which don't use escrowed keys, which I am unaware of?
First, I think the people who've spoken about document escrow are right. A much safer approach than key escrow. But I'm going to talk about key escrow, because there *are* decent ways to do it. There are methods for key escrow that don't involve a single trusted party having all the keys. For example, you can generate a dozen random strings of bits, XOR them together, then XOR the result with your key. Take the result of that operation and it's your thirteenth string. Now you can hand the thirteen strings out to thirteen different people. Now if you get hit by a bus, or if they are *ALL* ready to subvert the protocol by working together, they can get together, XOR all the strings together, and produce your key. A reasonable protocol for a company with fourteen board members, perhaps. There would be no way to serve thirteen out of fourteen board members with subpeonas and still have the investigation of the fourteenth board member be a secret to the company. Third, there are methods for key escrow with a single escrow agent that don't allow the escrow agent access to the key while it's still live. Take your August key on August First, and use a digital timelock to put one solid month of computing between the company escrow officer and the key. Hand the escrow officer the resulting blob, and use your key with impunity until August 30. On the 30th, you encrypt everything with your September key. On September 1, if she's put the fastest available machine to work on it the whole time, the escrow agent gets your August Key. Now, if you get hit by a bus during august, the escrow officer will be able to get stuff from your drive after august -- but will never have your key while that key is still in use. Fourth, the trusted third party doesn't need access to your keys. I could set up a web service that generated complementary asymmetric key pairs and published them thirty days apart. Now when Alice wants to put her key in storage for the company escrow officer, she can come to my site, pick up the key of the day, encrypt her key with it, and hand it to Bob the escrow officer. If Bob needed to use the key, and it were more than a month later, he could come to my site and get the complementary key and decrypt Alice's key. With this setup, I'm the only one that knows the decryption key, and I don't know diddley about what's encrypted under it or where anything encrypted under it is stored. Bear