Re: access to storage keys, NOT comms keys!
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`
participants (2)
-
Adam Back -
Anonymous