[723] in cryptography@c2.net mail archive
Re: Full Strength Stronghold 2.0 Released Worldwide
daemon@ATHENA.MIT.EDU (Matt Blaze)
Wed May 7 15:20:37 1997
To: Tom Weinstein <tomw@netscape.com>
cc: Adam Shostack <adam@homeport.org>, cryptography@c2.net
In-reply-to: Your message of "Wed, 07 May 1997 09:37:29 PDT."
<3370AFC9.2781@netscape.com>
Date: Wed, 07 May 1997 12:50:39 -0400
From: Matt Blaze <mab@crypto.com>
...
> One other problem is what to do about messages that are in transit when
> the key is lost. It may not be acceptable to just discard those
> messages, or ask them to be resent.
Isn't that what certificates and a key distribution system are for?
> > There are many good reasons to separate email communication keys from
> > email storage keys beyond the muddy key recovery issues. There are
> > obvious performance issues (local file protection requires only
> > secret-key techniques, which are, of course, much faster).
> > Functionally, cleartext email storage allows the use of standard tools
> > (I frequently grep my mailbox, but that doesn't work on any encrypted
> > messages stored there). More importantly, key management is greatly
> > simplified by separating these functions. The need to change public
> > keys and the need to change local storage keys frequently occur at
> > different times and for different reasons. The way current systems
> > are designed, even if I change (and revoke or expire) my public key, I
> > still have to keep the corresponding secret, forever, if I want to be
> > able to continue to read old messages.
>
> You assume that your mail is stored on your local disk. It may not be.
> It might be stored in a mail server, or it might be stored on a network
> file system. Other people may have access to your machine who you might
> not want reading your mail.
Huh? What does where the mail is stored have to do with whether it is stored
encrypted with the same key used to protect it in transit?
> > In any case, it seems to me that we need to have a clear understanding
> > of the properties and functions of different kinds of keys before we
> > start talking about the need to "recover" them. Key recovery, by its
> > nature, introduces a host of new problems that make the systems that
> > use it less secure, more expensive, and harder to analyze, and so we
> > need to be especially careful in selecting the keys that are exposed
> > to these problems.
>
> I agree completely. KR is only a valid solution for keys used for long
> term storage and in many cases key backup is a better solution.
What's the difference between "key recovery", "key backup" and "key
escrow"? For the purpose of understanding the basic problems (as
opposed to the implementation-specific problems), there probably is
no difference.
> Our problem is that there are large organizations that want to use
> secure mail. The administrators are held responsible for fixing things
> when they break, even if it's the user's fault. The only practical way
> that we've found to recover encrypted email in such a situation is KR.
>
Maybe, but I can find no reason to escrow communication keys, given an
architecture such as I described. Re-encrypt the mail (with an escrowed key)
for storage.
Don't get me wrong - I see an application for the ability to recover keys
in some cases, particularly for business email. But I think escrowing
the secret component of certified key pairs is probably the worst way to
do this, especially given the obvious alternatives.
-matt
