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 

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

Reply via email to