Have you ever thought about using a gpg key to encrypt something, but didn't due to worries that you'd eventually lose the secret key? Or maybe you did use a gpg key to encrypt something and lost the key. There are nice tools like paperkey to back up gpg keys, but they require things like printers, and a secure place to store the backups.
I feel that simple backup and restore of gpg keys (and encryption keys generally) is keeping some users from using gpg. If there was a nice automated solution for that, distributions could come preconfigured to generate encryption keys and use them for backups etc. I know this is a missing peice in the git-annex assistant, which makes it easy to generate a gpg key to encrypt your data, but can't help you back up the secret key.
So, I'm thinking about storing secret keys in the cloud. Which seems scary to me, since when I was a Debian Developer, my gpg key could have been used to compromise millions of systems. But this is not about developers, it's about users, and so trading off some security for some ease of use may be appropriate. Especially since the alternative is no security. I know that some folks back up their gpg keys in the cloud using DropBox.. We can do better.
I've thought up a design for this, called keysafe. The synopsis of how it works is:
The secret key is split into three shards, and each is uploaded to a server run by a different entity. Any two of the shards are sufficient to recover the original key. So any one server can go down and you can still recover the key.
A password is used to encrypt the key. For the servers to access your key, two of them need to collude together, and they then have to brute force the password. The design of keysafe makes brute forcing extra difficult by making it hard to know which shards belong to you.
Indeed the more people that use keysafe, the harder it becomes to brute-force anyone's key!
I could really use some additional reviews and feedback on the design by experts.
This project is being sponsored by Purism and by my Patreon supporters. By the way, I'm 15% of the way to my Patreon goal after one day!
You might want to check out libgfshare which already implements Shamir's method.
http://www.digital-scurf.org/software/libgfshare
I already use gfshare to shard my gpg key for backup, in a less secure way than keysafe.
But, if I implement keysafe in haskell, there's a nice pure haskell shamir library, http://hackage.haskell.org/package/secret-sharing
I relate to this usecase.
An approach for a backend: https://ripacrypt.download/
I was surprised to read the following snake-oily statement:
Upon reading that I thought that maybe you were referring not to the weak password, but to the derived key itself (though, that didn't make that much sense either).
But then I saw this:
Excuse me, but "19 entropy"? 19 bogons of entropy perhaps. Because "mom123" sure as hell does not have anywhere near 19 bits of entropy. In particular, for the case in question, that of password-cracking, it's much closer to 0. Also, things like that are in every dictionary and dictionary generator out there. So making claims about brute-force-resistance based on some foobar entropy count make no sense in my opinion.
@alkadim, I wonder what number of all the conversations that have included accusations of snakeoil have gone on to be constructive? I can only increment that number here by overwriting my original (predictively defensive) response.
"mom123" was being used internally as an rough example of a 19 bit entropy password, calculated per Shannon, so without using a dictionary. It should not have leaked out into the user-visible part of the documentation.
And of course it's referring to the time needed to crack the password in the context of keysafe, not time to crack it in the context of having a password file or something. The document explains why each password guess involves a 10 CPU-minute calculation and a 1 GPU-minute calculation.