Secret Sharing in GPG

[Dashamir Hoxha]

On 01/09/2016 09:52 PM, Sergi Blanch-Torné wrote:
> 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.

Yes, my idea is for a single user, with a key split in 3 (or more)
places. Then any two pieces need to be present in order to use the
private key. Similar to 2-step verification, but technically different.

> 
> 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

I expect help on this (code proposal, process, etc.)

Regards,
Dashamir

> 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: 0x8D6414F9.asc
Type: application/pgp-keys
Size: 23949 bytes
Desc: not available
URL: </pipermail/attachments/20160109/563ece63/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160109/563ece63/attachment-0001.sig>