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
