Anonymous <nobody@replay.com> writes:
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.
It's getting difficult to speak English around here, what with the GAKkers redefining the terms and issuing updates to the NewSpeak dictionary every month or so. "escrow" already meant an object kept safe for one's own benefit. Or it did, until the GAKkers perverted it, and redefined it's meaning to be backdoor for another person or organisations benefit (government/spook benefit in their case). Key recovery sounds like the process of using your backup plan to recover keys. You would think it means a plan to recover your keys in case you have a hard disk crash or whatever. Again for your own benefit. But no, with another new edition of the newspeak dictionary it suddenly means backdoor, master key for government or other organisation to access your communications. (I also might admit to a small amount of hyperbole, "dastardly evil government/spook/TLA master backdoor access" as compared to "backing up your hard disk now and then is a good idea". But hey, that's the way I feel about it.)
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.
Thank you. With the obvious caveat that any given user may not want this, but that if you are holding information for other people, that is the information is other peoples valuable property, and the machine belongs to that other person too, then you might find it useful to give them a copy of the storage encryption key in case of disaster. In fact if they are employing you, and the machine is theirs they might reasonably insist upon it. You clearly have the option not to store your own private information on the machine. In fact your employee may have policies discouraging you from doing so.
Schneier means the same thing with regard to "data backup".
The point about using the terms "data backup" and "data recovery", is that it attempts to highlight the falacy of the fundamental misconception buzzing around, as a result of the lastest issue of the newspeak dictionary released from DC, that it is "essential and in companies interests to be able to recover transient messages". This is bogus. What is important is recovering DATA (using your backup tapes to "recover" your data, when you have a disk crash). Jon Callas' attempted invocation of the "key recovery bad" / "data recovery good" mantra, was somewhat amusing in that he _was_ arguing for data recovery, whilst implementing key recovery (or at least transient communication message recovery).
(untransferable signatures)
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?
The legal beagles at your company will decide a policy for you designed to minimise your companies chances of being sued over the contents of your communications, and hence losing it's shareholders money.
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.
No, it's a solution to a problem. It's a solution to the problem that Tim just explored in more detail, and one that I gave a few short comments upon in one of my posts in this thread. If your company can't be proven to have authored a document, it reduces the value of that the document to an opponent doing attempting to do creative legal work and create a headache for you company when your archives are requested in a discovery process.
There may be patents on these technologies, too.
Don't think so. It's simple enough technology.
(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.
Yes it'll need special archival software; but you're providing an integrated business solution right. PGP Inc's (are you a PGP employee?), already includes a number of components. Key server, SMTP policy enforcer, PGP for business. I might also point out that the current PGP for CAKware (pgp5.5) solution also has the same problem. Just because the message is encrypted to a second recipient, is no guarantee that the user is archiving it for you. Say the user receives some email which is hot, hot, hot, and immediately purges it from the received folder on eudora, or netscape, or PGP for business. So, now what good is your CAKware going to do for you? You don't have the message. Therefore you have the same problem if you wish to guarantee access to messages.
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.
Look, I'm not in favour of CAK, or GAK, or any other snoopy business, PGP are the ones arguing for that. What I'm proposing is that firstly you don't encourage people to do it. But, if you're convinced that people will shop elsewhere unless you do provide archival facilities readable by the company, and snooping facilities, I'm arguing that you ought to do it in such a way that the resulting system isn't useful for _Government_ access to keys. So given that set of criteria I think it's entirely reasonable to say to clients who demand encrypted user archival: - You'll need new email clients on all your desks And reasonable to tell clients who demand that the archive be central, (to prevent users deleting archived messages that don't suit them) that: - You'll need to buy the LAN archive server module also I also think it's entirely reasonable to tell clients who demand snooping: - you're little brotherish SOBs - the client will send your LAN archiver a copy after the user has decrypted - the client will send you a copy of sent email prior to encryption So, to answer:
If he forgets, the business owner has lost access.
He won't forget: it will be integrated into pgp5.6 "for business for people who don't like GAK" PGP mail clients.
There will be extra training costs, and people will have to change their habits.
Well they're going to have to learn how to use pgp5.6, but frankly it's just as easy to use as pgp5.0 for personal security.
Besides being more complex to design and implement,
Oh come on, I think PGP Inc will be able to hack it. Most of the design I already worked out for them in the last few posts.
it will be harder to sell to customers.
And there's the rub. What comes first: profits, or selling out to the US government. I'm sorry, but I think PGP has sold out on this one. You can justify most of the aspects of the system I outlined in terms of security. It is more secure. Using forward secrecy is more secure again, and imposes the same restrictions anyway. You can therefore use the line: - you want to marginally easier to integrate snooping at the expense of security? - what if your competitors also get to read your communications? Also, might carry some weight: - PGP is the standard solution, it doesn't work that way, for security reasons. If you use competitors products which do work that way, you'll be unable to communicate with the rest of the world 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`