Splitting a GPG private key

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Apr 6 20:18:38 CEST 2015


Hi Alfredo,

On Mon 2015-04-06 11:16:14 -0400, Alfredo Palhares wrote:

> While looking for a way to store you passwords and share them across the
> company.
>
> We need to control access inside subdirectories and have a master GPG key that
> gets encrypted with all the other ones.
>
> We would like to keep very limited access to this key, and we're thinking on
> literally splitting the file between different people.

It's not clear from this what your goals are.

Do you want to require multiple people to come together to use that
secret key?  or do you want them each to have the ability to use the key
independently from each other?

The answer about what to do would depend on how you want the key to be
used.

It's not clear to me that we have a functional workflow to support the
first scenario (where multiple people must come together to use the
secret key) without a lot of overhead for the users.

My understanding is that the Tails community does something like this,
but they are a highly-technical group who are willing to custom-build
their own tools and to endure quite a bit of tedious and inconvenient
process to protect the safety of their users.

Consider that anyone who ever has access to the raw secret material of
the shared key can effectively make a copy of it and then use it
elsewhere in the future.

If you can define your desired use cases more clearly, maybe someone on
this list can propose an effective workflow for you.

> After a reading on the man pages, the --sk2k-mode and --s2k-count seem the
> option to go, while on  --s2k-cipher-algo --s2k-digest-algo  I have no idea what
> options to use.

I'm not convinced that any of the s2k-* options are relevant to this
particular question.  I recommend leaving them as the defaults, and
thinking more about what properties you really want from your tools and
your workflow first.


hope this helps,

           --dkg



More information about the Gnupg-users mailing list