Secret Sharing

[dashohoxha]

I like the idea of wrapping gpg in bash scripts, in order to simplify the terminology and workflow for the non-experts. And I don't think that it conflicts with keybase.io, actually it can make use of it (the commandline keybase) if needed. However I don't see any late developments. Is it abandoned or it is just finished?

Anyway, I think that secret sharing in GPG would be a useful feature. The idea is to split the secret key into 3 (or more) parts, so that any two parts are enough to reconstruct the original secret key, but any one of them alone is not sufficient to reconstruct it.

There is already a free library and tool that has an implementation of it:

• http://point-at-infinity.org/ssss/

If someone wants to do shared secrets, he can use both gpg and ssss-split/ssss-combine. Or he can can write wrapper shell scripts that combine both of them.

I also thought that this feature could be implemented by extending gpg itself (see: http://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030681.html) However it seems to be a bit difficult to do it in a generic way that does not make unneccessary assumptions.

On the other hand, on a wrapper script (like simplekey) it can be easier to make certain assumptions, in order to simplify the workflow. For example, when storing a share of the key on cloud, we can assume that we store it on Google Drive.

What do you think about implementing this?

[nyarly]

That's certainly an interesting idea. It may be a while before I can get to it, but I'd certainly accept a PR to cover the case. (It's not abandoned, but it serves its purpose for me at the moment as is.)

One thing about the overall goals of simplekey, though, it that it really does attempt to cover the majority use case without needing e.g. to be configured. I'm trying to imagine how a 3 part key would be constructed without needing configuration, and I'm at something of a loss. I can see the virtue in the feature - e.g. separating your master key into 3 parts, and not worrying about the loss of one of them - but it's also a feature that a less-interested user is unlikely to care about or manage properly; those parts should probably be written exactly once, for instance, right?

[dashohoxha]

On Sun, Jan 10, 2016 at 9:38 PM, Judson Lester notifications@github.com wrote:

That's certainly an interesting idea. It may be a while before I can get to it, but I'd certainly accept a PR to cover the case. (It's not abandoned, but it serves its purpose for me at the moment as is.)

It is not a problem if it takes some time. I may even try to submit a PR and we can improve it together until it is in a good shape (simple and easy to use).

One thing about the overall goals of simplekey, though, it that it really does attempt to cover the majority use case without needing e.g. to be configured. I'm trying to imagine how a 3 part key would be constructed without needing configuration, and I'm at something of a loss. I can see the virtue in the feature - e.g. separating your master key into 3 parts, and not worrying about the loss of one of them - but it's also a feature that a less-interested user is unlikely to care about or manage properly; those parts should probably be written exactly once, for instance, right?

With ssss you can split the key in 2 or more parts, and al least 2 of them are required in order to enable operation (sign or decrypt). We can use the convention that we split it into 3 parts (not more than 3). By convention, one of them can be save on the user's home, for example at ~/.simplekey/, or at $(pwd)/.key. The second one can be stored (by convention) on a usb device, on the path /.simplekey/. The user should know that he cannot work without mounting first the key device. The script can search the attached devices for the directory /.simplekey/, and if it does not find a suitable one, should ask the user to insert the key device.

During key generation, the script will also generate a third part of the key, for example backup-key.tgz and ask the user to store it on cloud or on a backup usb device. Or maybe we can provide a service on the cloud for storing and retriving it, so that the script does it automatically, without user interaction.

Besides the key generation process, there should be also a key recover process, in case that either the key usb device or the pc has been lost or changed. The recovery process will make use of one of the remaining (unlost) parts of the key, and the third part of the key which is stored on the cloud.

Regarding simplicity and usability, since two different parts of the key are needed to sign and decrypt, and just one of them is not enough, then the password of the key is not so important and it can omitted. Not having to remember and type a password makes the whole experience with GPG keys simpler (without compromising the security).

[dashohoxha]

I am closing this issue in favor of this one: https://github.com/dashohoxha/egpg/issues/8