Secret Sharing in GPG

[Damien Goutte-Gattat]

On 02/08/2016 04:40 PM, Dashamir Hoxha wrote:
> What do you think?

Well, I can’t say anything about a participation in GSoC, but since I 
already use a secret sharing scheme for my private master key, allow me 
to share some thoughts about GnuPG and secret sharing.


> My idea was about using SS (Secret Sharing) to make private key
> management easier and more reliable. This would envolve storing a
> partial key on the local PC/laptop where the work (sign/decrypt) is
> normally done, and storing a second partial on a smart-card.

The point of storing private keys on a smartcard is that your PC/laptop 
never sees the private keys. When a private key is needed, GnuPG sends 
to the card the data it wants to decrypt or sign, the smartcard then 
performs the operation itsef and sends the result back to GnuPG.

What you’re proposing would imply to fetch the partial key from the 
smartcard back to the computer, where it could be merged with another 
share of the key.

First, it’s not possible with the current specification of the OpenPGP 
smartcard (by design, you cannot *retrieve* a private key stored on the 
card, you can only *use it*). And second, this completely defeats the 
purpose of using a smartcard in the first place.

My private subkeys are on a smartcard and I do not use (or plan to use) 
secret sharing for them. I use secret sharing only for:

* the master private key (which is *not* on the smartcard);
* the backup of my whole private keyring (master- and sub-keys).


> In terms of `gpg` commands and options it could be decsribed like
> this: […]

I am not sure whether secret sharing needs to be implemented directly 
inside GnuPG.

Another approach is to use an external program solely responsible for 
reconstructing the private key and place it into GnuPG’s 
private-keys-v1.d directory where the GPG Agent will find it.

That’s the approach I use, with a small program I wrote for that purpose 
[1]. When I need my master private key (say, for certifying Bob’s key), 
I run GnuPG like this:

    $ gfsec-use -- gpg2 --edit-key bob at example.com

That gfsec-use program will reconstruct my private key if possible, 
spawn gpg2, and wait for its termination. When I am done, it will remove 
the private key file.

I believe there are two benefits with that approach:

1) there is no need to modify GnuPG;

2) the external program is in no way tied to GnuPG, it’s a generic tool 
that can be used to reconstruct any kind of secret, instead of only a 
GnuPG private key.

Now if your goal is to make secret sharing *easier*, I will readily 
admit that there is still a long way to go. The user still needs to 
manually split her key, dispatch the shares on her various devices, and 
fill in the configuration file required by gfsec-use. All of that could 
be automated, but again, it can be done *outside* of GnuPG, which would 
probably be much easier.

Some more remarks about this method:

*) It depends on GnuPG storing each private key in a separate file in a 
precise location (currently $GNUPGHOME/private-keys-v1.d/keygrip.key). 
If a future GnuPG version changes the location of the private key files, 
this method would break. But I assume that such a change would probably 
be discussed (or at the very least, announced) beforehand on that list.

*) It is mostly intended for *occasional* use, and it is probably not 
suited for the private subkeys you use on a daily basis. I only use it 
for my *master* key.

Anyway, that was just my thoughts on the matter. I do not know the 
position of GnuPG developers on secret sharing, and whether they would 
rather have that feature implemented in GnuPG itself.

Cheers,

Damien

[1] http://www.incenp.org/dvlpt/gfsecret.html
     (warning: ugly and under-tested code ahead ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160209/bddb6b68/attachment-0001.sig>