From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 17 Oct 1997 17:11:04 +0800
To: Adam Back <wprice@pgp.com
Subject: Re: anti-GAK design principles: worked example #1
In-Reply-To: <v04001b0eb06a3d206797@[205.180.137.244]>
Message-ID: <3.0.3.32.19971017015110.006afc90@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



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