[734] in cryptography@c2.net mail archive
Re: Full Strength Stronghold 2.0 Released Worldwide
daemon@ATHENA.MIT.EDU (Tom Weinstein)
Wed May 7 18:24:02 1997
Date: Wed, 07 May 1997 10:16:18 -0700
From: Tom Weinstein <tomw@netscape.com>
To: Matt Blaze <mab@crypto.com>
CC: Adam Shostack <adam@homeport.org>, cryptography@c2.net
Matt Blaze wrote:
>
> ...
>
>> 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?
What? If you send encrypted mail to me but I lose my key before the
mail arrives, how do I read the message? I can either get you to send
the message again using a new key (which may not be possible), or have
my key recovered. It may be acceptable in some cases to say that the
mail is lost. It is certainly not acceptable in all cases.
>>> 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?
You were talking about storing it in the clear. That may not be a good
idea if the storage is not secure.
As far as reencrypting it, existing mail protocols don't allow us to
do that for mail that's stored on the mail server. If the mail is
downloaded to the client and stored there, then certainly reencryption
would be an option. The only thing that works all the time is to just
leave the message alone and store it as it was in transit.
[ ... ]
>> 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.
Sorry. I'm using "key recovery" and "key escrow" to refer to a
centrally administered system. I'm using "key backup" to refer to
a local mechanism for backing up keys. I think of "key recover" as
being controlled by the network administrators, while "key backup" is
something the user does.
>> 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.
I agree. Mail transfer is weird, though, because it has some
properties of storage and some properties of communcation.
> 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.
If there's another solution to all of the problems, I'm all for it.
Certainly there are some things we can do that will decrease the need
for KR and we plan to do as much as we can. However, I think that
some problems will prove to be unsolvable in any other way.
--
You should only break rules of style if you can | Tom Weinstein
coherently explain what you gain by so doing. | tomw@netscape.com
