Secret Sharing in GPG

Mon Feb 8 16:40:37 CET 2016

GNU is participating in Google Summer of Code again this year,
and it can act as an umbrella organization for all of its subprojects:
 - http://www.gnu.org/software/soc-projects/guidelines.html
 - http://www.gnu.org/software/soc-projects/ideas-2015.html
 - http://lists.gnu.org/archive/html/summer-of-code/2016-02/msg00000.html

Can we propose the idea of adding key splitting support as a summer project?
Or maybe it is too difficult for a student to do in 2-3 months? Or maybe
sensitive
programs (like gpg) should not be trusted to the students? What do you
think?

Anyway, it is not clear to me how to proceed, who should submit the project
proposal, etc. But maybe subscribing and asking to this mailing list:
 - https://lists.gnu.org/mailman/listinfo/summer-of-code/
can clarify some questions.

As author of the idea I can volunteer to be a mentor, since I would like
to see this feature implemented. But it definitely needs some other
mentor(s) as well, who know the code and can guide the student,
check the quality of his code, etc.

Salam-Shalom-Peace,
Dashamir

On Sun, Jan 17, 2016 at 11:03 PM, Dashamir Hoxha <dashohoxha at gmail.com>
wrote:

> Thanks Werner.
>
> On Thu, Jan 14, 2016 at 11:17 AM, Werner Koch <wk at gnupg.org> 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:
>>
>>   http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=summary
>>   git://nwl.cc/ssd.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 nwl.cc>" was trying to accomplish:
>  -
> http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=tree;f=ssd;h=f8a4290d79f42792ae91889e721ee10aec605fea;hb=HEAD
>  -
> http://nwl.cc/cgi-bin/git/gitweb.cgi?p=ssd.git;a=blob_plain;f=secret-sharing.patch;hb=HEAD
>
> 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
> shares,
>     will save one partial key locally (on the keyring), one on the
> smart-card,
>     and one on `private-key-backup.tgz`, and then will erase the private
> key.
>     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
> another
>     partial key from the smart-card or from the local key ring, will
> reconstruct
>     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 store
>     the second one on the smart-card (replacing the old partial if it is
> there),
>     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
> key.
>     Then, it is the responsibility of the user to store the file
> `private-key-new-backup.tgz`
>     on the backup device (cloud or usb).
>
> I thought initially that this secret-key spliting and combining can be
> accomplished
> using the libraries or functions of this implementation:
> http://point-at-infinity.org/ssss/
> (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
> spliting
> 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.
>
> Salam-Shalom-Peace,
>
> Dashamir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160208/4dcde38b/attachment.html>