At 11:45 PM 10/15/1997 +0100, Adam Back wrote:
We'll instead take it as a given that pgp5.5 and pgp5.0 are GAK compliant because of CMR and that this is a bad thing.
I'll duck the 5.5 argument for now, but you're incorrect on 5.0. The PGP 5.0 key format includes separate keys for signature and privacy, which is a mostly good thing, and includes the ability to associate a group of keyIDs and flag bits with each privacy key. (or each set of privacy key + signature key?? Jon?) What semantics are attached to this association are dependent on the computer program, and PGP 5.0 does nothing CMRish with them, much less GAKish. OpenPGP could do anything it wants with the field, such as use it for keyids (or IPv4 addresses, since it's 32 bits) of keyservers with copies of the keys, or whatever. PGP 5.6 could at least take the case of multiple keyids and secret-share the session key between them rather than allowing any single key to access it.
The rest of Will's post seems to miss the point, so it seems to me that the best way to transfer understanding of how to use the anti-GAK design principles to design less GAK friendly systems is to present a worked example.
Good - we'll attempt to nitpick it at least as thoroughly as we're nitpicking PGP 5.5 :-)
- store a copy of the private half of the users PGP encryption key encrypted to the company data recovery key on the users disk. No. This is evil. Don't go there. Even with secret sharing, and especially without.
- (optional) design the software to make it hard to copy the data recovery packet from the disk, hide the data, bury it in keyrings, stego encode it, whatever, use your imagination. This is secutity by obscurity; not highly useful.
Possible objections: objection #1. what if disk burns? counter #1: backup your disk objection #2: users don't back up disks
Objection 3 - users _do_ back up disks - that means every backup tape or disk or server volume potentially contains your disk's encryption keys CAKked up with the Corporate Master Key, which is Bad, and wildly out of the user's control, violating one of your principles. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639