Re: [Cryptography] Backup is completely separate
On Mon, Sep 2, 2013 at 11:03 PM, John Kelsey wrote: > The backup access problem isn't just a crypto problem, it's a social/legal > problem. There ultimately needs to be some outside mechanism for using > social or legal means to ensure that, say, my kids can get access to at > least some of my encrypted files after I drop dead or land in the hospital > in a coma. Or that I can somehow convince someone that it's really me and > I'd like access to the safe deposit box whose password I forgot and lost my > backup copy of. Or whatever. > > This is complicated by the certainty that if someone has the power to get > access to my encrypted data, they will inevitably be forced to do so by > courts or national security letters, and will also be subject to extralegal > pressures or attacks to make them turn over some keys. I suspect the best > that can be workably done now is to make any key escrow service's key > accesses transparent and impossible to hide from the owner of the key, and > then let users decide what should and shoudn't be escrowed. But this isn't > all that great an answer. > To avoid mandated/coerced release substitute 'keep at bank' with 'bury at undisclosed location'. There is really no 100% reliable way to make things available to your heirs while avoiding government coercion. Particularly since the government issues the documents saying that you are dead. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Backup is completely separate
The backup access problem isn't just a crypto problem, it's a social/legal problem. There ultimately needs to be some outside mechanism for using social or legal means to ensure that, say, my kids can get access to at least some of my encrypted files after I drop dead or land in the hospital in a coma. Or that I can somehow convince someone that it's really me and I'd like access to the safe deposit box whose password I forgot and lost my backup copy of. Or whatever. This is complicated by the certainty that if someone has the power to get access to my encrypted data, they will inevitably be forced to do so by courts or national security letters, and will also be subject to extralegal pressures or attacks to make them turn over some keys. I suspect the best that can be workably done now is to make any key escrow service's key accesses transparent and impossible to hide from the owner of the key, and then let users decide what should and shoudn't be escrowed. But this isn't all that great an answer. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Backup is completely separate
So I was thinking about Jon's claim that keys should be 'disposable'. Not sure if I buy that. But I did decide that key backup is a completely separate problem and demands a separate infrastructure. Let us imagine that I do the key-splitting and share in 5 places thing for my Comcast email. I probably need the same for my file system backups as well. And I probably want to be able to rely on the same in the future if I roll keys or whatever. So the way to deal with that problem is to have a separate key escrow protocol. Probably a JSON Web Service. The protocol results in a 'key escrow identifier' which is essentially just a retrieval index on the public key. So mine might be CBK:w9idkw992ksl3. Whenever I initialize a new public key, I give the keygen system that URI and that provides the information necessary to do a backup against my escrow setup. To check that I have the right one the system comes back and says 'Daleks are bad' which is the check phrase I chose when I initialized the system. Beneath the covers the backup scheme is simply locating a public key cert that matches the hash code I gave it, encrypting the private key under the specified public and sending the package to the email address registered in the cert. Probably want some sort of escrow agent that can be trusted to keep the encrypted bits of the private key pair and not lose them (Fort Meade would serve for that) and give them back when needed (ok, Google then). The reason I suggest a hash rather than a domain name is that this system has to work for decades and domain names are not stable enough over those periods. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
