Secret Sharing in GPG

Dashamir Hoxha dashohoxha at
Sun Jan 17 23:03:56 CET 2016

Thanks Werner.

On Thu, Jan 14, 2016 at 11:17 AM, Werner Koch <wk at> wrote:

> Hi,
> if you are interested in Secret Sharing you may want to look in Phil
> Sutter's implementaion of a secret sharing daemon for GnuPG from 2008:
>   git://
> There has not been much interested in it back then but it may give you
> some ideas and code.

>From the code and the README files, it is not clear to me what "Phil Sutter
<phil at>" was trying to accomplish:

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.
So, without the smart-card the key cannot be used. But the smart-card alone
is not sufficient
for using the key (for example if it used in a different PC/laptop).

To protect against key loss (for example when the smart-card or the laptop
is lost),
we also generate a third partial key and store it in a backup media. This
backup media
can be a usb device locked in a safe. However it is also Ok to store it in
the cloud
(for example I am using Google Drive to store my data).
We can also store the third partial in two different backup media (for
example both
on usb and on cloud).

In terms of `gpg` commands and options it could be decsribed like this:

1. When generating a new key use the option `--split` like this:
     `gpg --gen-key --split`

    Without the option `--split` the command will have the normal behaviour
    of just generating a new key pair.
    With `--split` it will require a smart-card to be present, otherwise it
will fail.
    After generating the key pair, it will split the private key into 3
    will save one partial key locally (on the keyring), one on the
    and one on `private-key-backup.tgz`, and then will erase the private
    It is the responsibility of the user to store `private-key-backup.tgz`
    on a proper backup device (cloud, usb or whatever).

2. When an operation that needs the private key is requested (either sign
or decrypt),
    if only a partial key is available (not the whole private key), then
the presence of the
    smart-card will be required. Then the partial key of the smart-card
will be combined
    with the local partial key in order to reconstruct the private key, the
private key will
    be used to complete the operation, then the private key will be erased.

3. Assuming that the smart-card or the laptop has been lost (one of the
partial keys
    has been lost), we should be able to recover the private key like this:
    `gpg --recover-key --backup-file=private-key-backup.tgz`

    This will get the partial key from `private-key-backup.tgz`, will get
    partial key from the smart-card or from the local key ring, will
    the private key, will generate three other partial keys, will save one
of them
    on the local key ring (replacing the old partial, if it is there), will
    the second one on the smart-card (replacing the old partial if it is
    will store the third partial on the file `private-key-new-backup.tgz`
(and will
    delete `private-key-backup.tgz`), and finally will erase the private
    Then, it is the responsibility of the user to store the file
    on the backup device (cloud or usb).

I thought initially that this secret-key spliting and combining can be
using the libraries or functions of this implementation:
(just port them to gpg).

However I noticed at the example at the end of the page that it says:
"Enter the secret, at most 128 ASCII characters"
So, it is not possible to use it for spliting a RSA private key, which is
much longer
than this. I don't know whether this is a limitation of the algorithm, or
it is just
a limitation of the implementation, and it can be fixed.

However, it says at the end of the page that for large keys, instead of
the key itself, we can split the password. This could complicate a bit the
implementation, but I think that it is still can be done.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160117/f71746d6/attachment-0001.html>

More information about the Gnupg-devel mailing list