From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 18 Oct 1997 01:46:57 +0800
To: stewarts@ix.netcom.com
Subject: Re: anti-GAK design principles: worked example #1
In-Reply-To: <3.0.3.32.19971017015110.006afc90@popd.ix.netcom.com>
Message-ID: <199710171727.SAA00990@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Bill Stewart <stewarts@ix.netcom.com> writes:
> 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,

A very good thing.

> and includes the ability to associate a group of
> keyIDs and flag bits with each privacy key.

So can you use pgp5.0 to construct a CMR key which would
interoperate with pgp5.5 for business?

> 	(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.  

Clearly pgp5.0 does nothing with these flags on reciept, but does it
understand them when sending?

Scenario: I work for Mega Corp, and it is using pgp5.5, and is using
CMR with companies key.

Does pgp5.0 reply encrypting to just me as individual, or two crypto
recipients me, and Mega Corp recovery key?

I would be interested on clarification of this point.

> 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.

Yes, I'm not so much arguing about the flexibility or the mechanism,
as what it is being used for.  I consider there are more secure and
more GAK resistant ways to acheive same functionality.

> >- 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.

It is evil.  But it is not _as_ evil.

The reason for this is that government access to storage keys is not
as evil as government access to communications keys, because the
government has to come and capture the ciphertext (take your disk),
whereas with communications they can grab them via an arrangement with
your ISP.

> >- (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.

Indeed.  It is of only marginal use.

> >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.

See point above.

This is not avoidable for storage ... if you are encrypting data on
disk, and if you want recovery information, you have no choice but to
allow company access.

The recovery information should be as decentralised as much as
possible.  (Perhaps this should be the Stewart corollary).

The point though is that storage recovery is a completely separable
issue from communications "recovery" which is a euphamism for allowing
companies to read, or snoop, employees email, unless it is being used
soley for data recovery of mail stored in mail folders (which seems to
be what PGP Inc means by CMR term), in which case it is not necessary
functionality, and can be better acheived by encrypting the mail
archive with a user symmetric key with company storage recovery on
that key.

I would be interested to hear novel ways to minimise the likelihood
that the government could walk into your offices, grab the CD duke
box, grab the single corporate recovery key and walk off.

Decentralisation is one good way -- recovery keys are in hands of
department and group heads -- secret splitting is another good way --
and (your suggestion) omitting some of recovery bits is a small
addtional hinderance to intruders after plaintext.

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`