Key escrow

[bkeepers]

It should be easier to use the app from multiple devices. To do that, we need an easy way to get the key on those devices. A few ideas:

1. Implement a separate key store service that will save private keys. This should be completely separate from the central data store and ridiculously secure.
2. Save the key to dropbox. This could even be as an HTML file, which has a big link to the app with the key as part of the hash, which could then be copied into localStorage
3. Google Authenticator or something like it. I think this requires that the server has the key, so this probably isn't a great option if we want to keep the keys off the server.

[cobyism]

There was also that idea about using a QR code to transfer between
desktop/laptop and mobile devices 😀

On Wednesday, January 16, 2013, Brandon Keepers wrote:

It should be easier to use the app from multiple devices. To do that, we
need an easy way to get the key on those devices. A few ideas:

1. Implement a separate key store service that will save private keys.
   This should be completely separate from the central data store and
   ridiculously secure.

2. Save the key to dropbox. This could even be as an HTML file, which
   has a big link to the app with the key as part of the hash, which could
   then be copied into localStorage

3. Google Authenticator or something like it. I think this requires
   that the server has the key, so this probably isn't a great option if we
   want to keep the keys off the server.

   —
   Reply to this email directly or view it on GitHubhttps://github.com/Key escrow #68.

[zef]

Dropbox is a nice solution, but it's too permanent and provides a the context about who the key belongs to.

Instead of a true store service I like the idea of sending them in a transient manner like This Message Will Self-Destruct.

Flow could work something like this:

1. User requests to send private key
2. Private key is securely stored without any context about owner, identified by a UUID
3. UUID is transferred to the client receiving the key, mechanism doesn't matter but could go through swordfish account.
4. Client requests the key, the key is sent and immediately destroyed

Temporary passcode protection could go on top of this too, like they do with This Message Will Self-Destruct.