
Adam Back <aba@dcs.ex.ac.uk> writes:
I'm arguing that you should not backup, or escrow communications keys, and that you should backup storage keys.
Euphemism alert: when we are talking about the kind of data recovery we like, we call it "backup". When we are talking about the kind we don't like, we call it "escrow". Schneier did the same thing: Bruce Schneier:
Key escrow = someone other than the author or the intended recipient of the message being able to decrypt it.
There are valid reasons for data backup, but they have nothing to do with crypto key recovery.
You don't actually mean that you should backup storage keys, you mean you should provide a means for someone other than the user to decrypt that stored data. Schneier means the same thing with regard to "data backup".
(forward secrecy)
This could be a good idea, particularly in terms of old keys leaking out, but it needs more work. It's not clear that any of the forward secrecy methods will work for email. You can't easily do a DH key exchange via email because of the multiple messages. Maybe you could piggyback on ordinary messages, and after a few have been exchanged, you can get a DH key for the next message, but this is very complicated. Synchronization isn't guaranteed with email, neither is reliable delivery.
(untransferable signatures)
This is also a good idea, but it needs more work, too. There is a big education problem here. People barely understand the implications of regular digital signatures. Now you are throwing this new kind in, which guarantee the message came from another person, but aren't binding. What happens when an employee receives a message from a supplier signed with that kind of signature? Can he make a decision on that basis, or not? In paper business correspondence, there is no such distinction. A signed letter is transferable. Go beyond this and business will be scratching its heads. It's a solution looking for a problem. There may be patents on these technologies, too.
(re-encrypting email with an escrowed key for archival)
This is going to require special archival software and special actions on the part of users. You won't be able to do it as a transparent plugin. The user can't save his mail the regular way (with some email packages), he has to remember to (also?) save it to the business access archive. If he forgets, the business owner has lost access. There will be extra training costs, and people will have to change their habits. Besides being more complex to design and implement, it will be harder to sell to customers.