Loss of Private Key

[jhleath]

Assume for a moment that a user or service has lost control (via leaking, copying, or actual loss) of their ECDSA private key.

What steps can we take to either mitigate this risk or seamlessly transfer the user to a new address?

[jhleath]

We need to think about using a different signature method. One in which a 'master' key can sign 'slave' keys. Therefore, if a user loses control of his or her 'slave' key - he or she can still send and receive mail AND revoke that key.

But, this is for the future. The near future. Hopefully.

[brentbaum]

This problem makes me very nervous.

[jhleath]

I think that we can take solace in the fact (at least for now) that we use exactly the same signature algorithm as BitCoin (exactly in this context of course means that we use a different curve).

So, in BitCoin (where people trust their money), you lose your key - you lose your money. In addition to that, your computer gets a virus or someone can take access of the key? They steal your money. Now, I don't think that BitCoin is very user friendly - something that we hope to aspire to. Which is the purpose of the bug. However, we can still have a MVP without fixing this.

I do think that the beauty in fixing it comes in many flavors - once we have a 'master' key that can randomly sign 'slave' keys into existence, then we can authorize keys based on device usage (that way we don't have to pass the private key around). Or application usage. Or anything. But, then we have an OAuth-style revocable keychain.

[brentbaum]

Good points. So where would the master key be stored? Mailserver level?

[jhleath]

That's the problem that I haven't found a solution to. Because, even then, someone could get access to their account (we could probably mitigate the risk of the attacker getting the private key by only allowing export through the hypothetical Porting Protocol - actually, that doesn't make any sense).

My 'grand vision' was that we would have some kind of backup that only the user had either in paper with a series of number printed, qr code, etc. Because then we wouldn't have to worry about security. We should look into how people do the physical bitcoins - there could be something there.

But the other thing is that if the key is stored in the mailserver, then there wouldn't be any reason for the user to have to regenerate the keys for use on other devices. You know? Unless the mailserver only has a slave key...

If you couldn't tell, my thoughts are literally all over the place on this. Security is so important, and I want to make sure that we do it in the best way possible. I am just not sure what that is right now...

On Jul 17, 2013, at 12:50 PM, Brent Baumgartner [email protected] wrote:

Good points. So where would the master key be stored? Mailserver level?

—
Reply to this email directly or view it on GitHub.

[brentbaum]

Yeah, that was where I was really getting hung up. Store it on the server, and the whole system has the potential to get very very centralized. Store it on the user's computer, and a virus or an accidental rewrite (I'm embarrassed to admit how many times I've accidentally overwritten my private ssh key) is fatal to that user's data.

I like the idea of an Oauth-style revokable keychain, but again, it seems that relies on a more centralized system.

I'll look into physical bitcoins once I get off work today. A quick google turned up some interesting results.

I don't blame you for being indecisive on this one. Cryptography and security make me nervous in general, as the product has to be completely perfect or else it's totally useless. That said, you can definitely figure it out :)