Secret Sharing in GPG

[Sergi Blanch-Torné]

Hello Dashamir,

I think you have pointer many scenarios. Perhaps they can be reduced.
The key generation in a (k,n)-threshold, I think, should be made at
once. The key is the 'n' elements produced as an output. Later when the
secret key will be used, only 'k' fragments are needed to recover the
secret. (k<=n)

Correct me if I'm wrong, but to open the locker, the 'k' elements needed
have to be present at the same time to recover the secret that will be
used like a secret key for the cryptographic operation. Perhaps there
are some research that proposes how it can be made with offline
interaction between the participants. Besides that, I'm not sure if your
idea is only for a single user with a key split in many places.

You can do a code proposal based on the schema of secret sharing. But be
sure to learn in an early stage how to proceed for an appropriate
contribution. Imho, it should follow an standardization process and peer
review. My contribution, long a go, didn't follow well the path and I
think this has slowed the process to have it publicly available.

Regards

/Sergi.

On 08/01/16 23:26, Dashamir Hoxha wrote:
> Hi,
> 
> I think that secret sharing in GPG would be quite 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.
> However it would be more convenient if gpg can do it out of the box.
> 
> I think that using secret sharing has some advantages. For example
> imagine some scenarios like these:
> 
>  - A user generates a new key and he tells `gpg` to share the secret key
>    (or it can be the default option). Then `gpg` saves a share of the
> key locally,
>    saves another share on a removabe device (smard card or usb), and uploads
>    a third share somewhere on the cloud, where only the user has access.
> 
>  - When the user needs to do something with the private key (sign or
> decrypt),
>    he has to insert first the removable device with the key share. Then
> `gpg`
>    will combine this share with the one stored locally, will reconstruct
> the private
>    key, will use it, and then will erase the key again.
> 
>  - If somebody gets temporary access to your removable device, they cannot
>    find your private key, because the one share that is stored in it is
> not enough
>    to reconstruct the private key. The same if someone gets access to your
>    computer. They need to have access both to your computer and your dongle
>    in order to be able to sign with your key, and then maybe they will
> also need
>    to know the passphrase of the private key.
> 
>    The same can be said if somebody gets access to the share of the key that
>    is stored on the cloud. They need to get another share (either the
> dongle or
>    your pc), in order to reconstruct the key. 
> 
>  - If the dongle is lost or stolen, your private key is not compromised.
>    In this case you can get the share of the key from the cloud, combine it
>    with the share of the key on the pc in order to reconstruct the key,
>    then rigenerate three new shares: one for the pc, one for the dongle
>    and one for the cloud, and delete the old shares from the pc and the
> cloud.
>    Destroying the old shares effectively invalidates the lost share, because
>    alone it is useless for reconstructing the key.
> 
>  - If the pc is lost or changed, you can get the share stored on the cloud,
>    combine it with the share stored on the dongle, reconstruct the key,
>    rigenerate three new shares, store them on the pc, dongle and cloud,
>    and finally delete the old shares from the dongle and the cloud.
> 
> I think that this would make key management safer and more robust.
> Maybe it is not the ultimate solution, but at least it could prevent some
> cases like loosing the private key because you lost the smart-card,
> or because you changed the pc and forgot to transfer the keys from
> the old one to the new one (or you just lost the pc).
> 
> I hope that the idea that I am trying to explain is clear, but if needed
> I may
> also try to draw some diagrams, to make it easier to understand.
> 
> However I have no idea about how this can be implemented on GPG, or how
> to get started. I even know a student who is interested in trying to
> implement
> this as his master project, I have promissed to help and guide him, but
> I am not
> able to give him any advice or hint at all about how to get started.
> 
> Would somebody be willing to help and guide this student to implement this?
> Or maybe this should be managed as a "Google Summer of Code" project?
> 
> Thanks and regards,
> Dashamir
> 
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160109/7452a3ed/attachment.sig>