Re: access to storage keys, NOT comms keys!

From: Anonymous <nobody@REPLAY.COM>
Date: Thu, 9 Oct 1997 10:27:28 +0800
To: cypherpunks@cyberpass.net
Subject: Re: access to storage keys, NOT comms keys!
Message-ID: <199710090215.EAA02470@basement.replay.com>
MIME-Version: 1.0
Content-Type: text/plain
Here is what leading cryptographers say about email key recovery, from
http://www.crypto.com/key_study/report.shtml. This includes respected
figures like Bruce Schneier, Matt Blaze, Ron Rivest, Ross Anderson,
Whit Diffie, and more.
2.1 Communication Traffic vs. Stored Data
While key ``recoverability'' is a potentially important added-value
feature in certain stored data systems, in other applications of
cryptography there is little or no user demand for this feature. In
particular, there is hardly ever a reason for an encryption user to want
to recover the key used to protect a communication session such as a
telephone call, FAX transmission, or Internet link. If such a key is lost,
corrupted, or otherwise becomes unavailable, the problem can be detected
immediately and a new key negotiated. There is also no reason to trust
another party with such a key. Key recoverability, to the extent it has
a private-sector application at all, is useful only for the keys used
to protect irreproducible stored data. There is basically no business
model for other uses, as discussed below.
In stored data applications, key recovery is only one of a number of
options for assuring the continued availability of business-critical
information. These options include sharing the knowledge of keys
among several individuals (possibly using secret-sharing techniques),
obtaining keys from a local key registry that maintains backup copies,
careful backup management of the plaintext of stored encrypted data, or,
of course, some kind of key recovery mechanism. The best option among
these choices depends on the particular application and user.
Encrypted electronic mail is an interesting special case, in that it
has the characteristics of both communication and storage. Whether key
recovery is useful to the user of a secure E-mail system depends on
design of the particular system.
The government, on the other hand, proposes a key recovery infrastructure
that applies to virtually all cryptographic keys, including (especially)
those used to protect communications sessions.
They say that key recovery is not appropriate for transient keys used
during a communication session. However, email is a special case, having
characteristics of both communication and storage. In some systems,
email may be archived for long periods of time in the same format that
it was received. For such systems there is a business case for key
recovery in email.

Anonymous <nobody@REPLAY.COM> writes:
> [7 cryptographers report says]
> 
>    Key recoverability, to the extent it has a private-sector
>    application at all, is useful only for the keys used to protect
>    irreproducible stored data. There is basically no business model
>    for other uses, as discussed below.

Right.

>    Encrypted electronic mail is an interesting special case, in that it
>    has the characteristics of both communication and storage. Whether key
>    recovery is useful to the user of a secure E-mail system depends on
>    design of the particular system.

I was arguing for designing the system so that as much of the storage
functionality as possible is accomplished with separate storage keys.

> They say that key recovery is not appropriate for transient keys
> used during a communication session.  However, email is a special
> case, having characteristics of both communication and storage.  In
> some systems, email may be archived for long periods of time in the
> same format that it was received.  For such systems there is a
> business case for key recovery in email.

So the solution is to engineer your email system to re-encrypt email
to a storage key before archiving.

You lose a couple of functionalities over a true key escrow system,
which a previous anonymous (don't know if you're the same anonymous)
identified well:

- if someone leaves / dies unexpectedly you can't decrypt email in
  their mail box.

- if the employee who is the crypto recipient refuses to decrypt the
  company won't be able to decrypt either.

However there are a couple of reasons why this isn't such a big deal,
and why people ought to get used to it.

i) How often do people die unexpectedly -- if this does happen the
company faces other similar problems, perhaps said employee had a few
things on a `to do' list stored in only in his head.  Perhaps he has
contacts the company doesn't have recorded.  The company will have to
do some extra work reorganising anyway.

ii) You can't avoid above problems if you're using forward secrecy;
you should be using forward secrecy for security reasons, so you'd
better get used ot the side-effects.

iii) You can minimise the negative effects if you ensure that the
people sending you email also have a matching system which ensures
that `official' sent email is all backed but up encrypted with a
storage key.  Then they _will_ have the email to resend.  This seems
likely in any event, if the importance of the email exchanges is so
important that the company wants to archive it, the sending company is
likely to also.  If the email gets lost in transit you'll need a copy
to resend already.

iv) It's worth the minor extra inconvenience because you can then plug
in forward secrecy, and you thereby have a double stance against GAK:
no key escrow, and no long term private encryption keys as fat
targets.  As a plus it's a security improvement also.

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`