From: Alan Barrett <apb@iafrica.com>
Date: Tue, 13 May 1997 01:56:06 +0800
To: cypherpunks@cyberpass.net
Subject: Re: key recovery vs data backup
In-Reply-To: <19970511024334.53652@bywater.songbird.com>
Message-ID: <Pine.NEB.3.95.970512110252.21416I-100000@apb.iafrica.com>
MIME-Version: 1.0
Content-Type: text/plain


On Sun, 11 May 1997, Kent Crispin wrote:
> In the multiple recipient case, therefore, the master 
> key is potentially used quite frequently, and hence much more 
> exposed.  There are many other differences: I won't try to go into 
> detail here.

Good point.

I happen to think that using the master key to decrypt documents is better
practice than using the master key to obtain copies of other keys, but I
can see both sides of this argument.

> > > What part of the organization that is Acme Corp is authorized to know
> > > this particular bit of information?
> > 
> > Whatever the answer to the latter question is, it's the same in the CAK
> > case as it is in the "encrypt to a special coprorate key" case.
> 
> Not if the encryption client encrypts to different company recipients
> depending on a policy (which one might want if one tries to limit the 
> compromised master key problem described above.)  Then the policy, 
> contrary to what you state below, must be reflected in the client.

You are repeating your fallacy of assuming that the key safe (KS) case has
one policy for all users and the multiple recipients (MR) case has
different policies for different users.  The truth is that the two issues
(which model to use, and how many different policies to make visible to
the users' software) are orthogonal.  You can have KS with a different key
safe for each user, and you can have MR with the same extra recipients for
each user.

> > > Because some of the employees are idiots you want this
> > > built automatically into the application they are using for
> > > encryption/email/whatever.  How does this software know what policy
> > > is appropriate for which employee?  How is that policy distributed?
> > > What is the interface that allows a policy to be defined?  How do you
> > > protect the policy definition from subversion?
> > 
> > The same problems arise in the CAK case.  And the same solution: you
> > make the user's software do the same thing every time, and implement the
> > policy elsewhere.
> 
> Sigh.  The situations are really quite different.  In the KS
> case the policy never impacts the software; in the MR case I don't 
> think you can avoid it.

Sigh.  The same fallacy again.

In the KS case, the software must know which key safe to use and how to
secure and authenticate access to the key safe.

In the MR case, the software must know which extra recipients to add, and
the corresponding public keys.

In both cases, the software is affected to some minimum extent.  In both
cases, you can choose to make the software more complex by adding more
policy knowledge.  In neither case are you forced to add more than the
minimum amount of policy information to the software.

> > > Access to the key-safe is critical, of course, but it can be made very
> > > secure -- a special-purpose piece of hardware that requires passwords
> > > from n out of m key czars before access is granted, for example.
> > > Or the contents of the key safe can be encrypted via keys escrowed
> > > through a secret sharing mechanism
> > 
> > The same problems and solutions apply in both the CAK case and in the
> > "corporate key as extra crypto recipient" case.
> 
> Not at all. The corporate master key is used to decrypt documents in the 
> MR case; in the KS case the master key is used to get to the key 
> database.

What I meant was, you can make n-of-m hardware stuff for both cases.
Surely you don't disagree with that?

> >   - With CAK, every time a user creates a new key, the user's software
> >     needs to talk to teh key safe.  This needs a secure channel, which
> >     raises further authentication problems (how does the user know that
> >     he's not talking to a fake key safe).  These don't arise in the
> >     non-CAK case.
> 
> Not so.  You have to exactly the same issue -- how does the user find 
> out the master key to encrypt to?

Finding out which key to encrypt to in the MR case is analagous to finding
out which key safe to talk to in the KS case.  Securing and authenticating
the channel to the key safe in the KS case is an extra issue that does not
have a counterpart in the MR case.

--apb (Alan Barrett)