Secret Sharing in GPG

[Dashamir Hoxha]

Damien, thanks for sharing your insights and experience.

On Tue, Feb 9, 2016 at 12:51 PM, Damien Goutte-Gattat <
dgouttegattat at incenp.org> wrote:
>
>
> 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.
>

I didn't know how a smartcard works, thanks for explaining it.


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

Yes, indeed, this is what I had in mind. But if the smartcard has a
processor and it can decrypt or sign messages, maybe the computer can send
the partial key along with the data, and the smartcard can reconstruct the
key before processing the data. I don't know whether it can work this way
and whether it is possible.


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

I don't think it defeats the purpose of using a smartcard, it only improves
it. One of the benefits would be that the passphrase or the pin that is
used to secure the secret key now becomes totally optional, and it can be
omitted without reducing the security. If the card is lost, no problem,
nobody will be able to use the key, even though it has no pin or
passphrase. Another benefit is the secure backup. If your card is lost,
your key is not lost, and you can use a brand new card with the same key.
In my opinion, not having to remember a pin or a passphrase is very
important, because it is used very rarely and it is quite possible to
forget it (I have forgotten myself a bunch of important passwords during my
life).


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


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

However, implementing it directly in GnuPG does have some benefits:

1) you don't need any extra tools to handle it

2) it can be much easier to use than any extra external tools

3) any programs that depend on GnuPG (and there are lots of them) can
directly benefit from it, without having to reimplement it each one of them
on its own

In my opinion, the last one is the most important.


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


Yes, this is one of the goals too, to make gpg key management easier in
general.


> *) 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.
>

A suggestion: why don't you use gpg commands for import, export and delete?
This way you don't need to worry about implementation details (where and
how does GnuPG stores the private keys, etc.)


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

Thanks for sharing it anyway.
By the way, I am thinking of starting a project for simplifying the gpg key
management for the beginners. This will be a shell script (or a bunch of
shell scripts) that will wrap gpg commands, trying to make the workflow
easier and more understandable. I am thinking to start by cloning this
project: https://github.com/nyarly/simplekey
Is anybody interested in joining, helping, providing feedback, etc.?

Cheers,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160209/9c2900c4/attachment.html>