Re: access to storage keys, NOT comms keys!

[Adam Back <aba@dcs.ex.ac.uk>]

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`