Secret Sharing in GPG
dgouttegattat at incenp.org
Tue Feb 9 12:51:36 CET 2016
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
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
. 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.
(warning: ugly and under-tested code ahead ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel