We are a group and each member have an independent PGPKey, but we want to read messages encrypted for the group.

I create a pair with an only one key only for encryption, but I don't want to share this key with all members, against, I want toshare the encyption subkey to allow each member to decrypt messages encrypted for the group.

The problem is; I don't find how to import a secret subkey to a key with gpg (GNUPg).

Is it possible?


I think you could do it that way:

  1. Generate your key pair, or use your existing key:

    pub   rsa2048/E777DCBD 2017-06-16 [S]
    Key fingerprint = 27F6 F30D EA60 B720 85EF  AF89 358C 5737 E777 DCBD
    uid         [ultimate] Testing
    sub   rsa2048/05662D7C 2017-06-16 []
  2. Next, use gpg --edit keyid on that key and add the signature, etc. subkeys that you want using the addkey keyword and then save it to store this newly created subkey on the keyring. (Or only use the default encryption subkey, and do nothing...) For the sake of the example, I've added encryption, sign and auth subkeys (using the gpg --expert --edit keyid command to set my own capabilities on the subkeys) to my master key:

    sec  rsa2048/E777DCBD
         created: 2017-06-16  expires: never       usage: SC  
         trust: ultimate      validity: ultimate
    ssb  rsa2048/05662D7C
         created: 2017-06-16  expires: never       usage: E   
    ssb  rsa2048/8D9F7D0A
         created: 2017-06-16  expires: never       usage: E   
    ssb  rsa2048/4852B177
         created: 2017-06-16  expires: never       usage: A   
    ssb  rsa2048/105B24A3
         created: 2017-06-16  expires: never       usage: S   
    [ultimate] (1). Testing

    Note: when you have two encryption subkeys like here, the most recent one is used by default.

  3. Create a backup of the whole key (secret and public) using gpg --export -a keyid > commonpubkey.asc and gpg --export-secret-key -a keyid > masterseckey.asc. There you should take the usual PGP cautions and copy those files onto a secure offline storage.

  4. It is also important now to backup your whole keyrings, because the next step will mess it up.
  5. So, now you only want to take one of the subkeys, so you can: gpg --edit keyid and delete all the subkeys that you don't want to share (to do so, you have to first mark them with key n and delete them with delkey) and save:

    sec  rsa2048/E777DCBD
         created: 2017-06-16  expires: never       usage: SC  
         trust: ultimate      validity: ultimate
    ssb  rsa2048/8D9F7D0A
         created: 2017-06-16  expires: never       usage: E   
    [ultimate] (1). Testing
  6. Finally the magic gpg --export-secret-subkeys -a keyid > sharedseckey.asc will allow you to export only the remaining subkey, without any other keymaterial from the primary key!

So you can finally restore your keyrings (you'll need to restore both the secret and public one, because when you delete a subkey, you also delete your public subkey), and you're back to owning the whole key, with all subkeys and proper keymaterial.

The next step is for your colleagues:

  1. On their machine, they need to do a gpg --import commonpubkey.asc commonseckey.asc (with those two files you've previously generated).

Et voilà, you're all ready to use gpg.

To verify that your colleagues really don't have any secret keys you don't want them to have, have a look at the output of gpg --list-secret-keys, you'll see that this key without the primary secret key is marked with a '#':

sec#  rsa2048/E777DCBD 2017-06-16 [SC]
uid         [ unknown] Testing
ssb   rsa2048/05662D7C 2017-06-16 [E]
ssb   rsa2048/8D9F7D0A 2017-06-16 [E]
ssb   rsa2048/4852B177 2017-06-16 [A]
ssb   rsa2048/105B24A3 2017-06-16 [S]

They also won't be able to sign or authenticate since they won't have those subkeys, but if you sign something with your key, the common pubkey will still be able to verify it.

So in the end, they will not import the subkey, but the whole key, but without primary keymaterial, with only the keymaterial of the encryption subkey you'll have left there. But this is the way to go instead of trying to add this common encryption subkey to their own key, since it would then mean that when you encrypt something for them you'll have encrypted it for the whole group, since the newest encryption subkey of a public key is used by default to encrypt by gpg...

So you really don't want them to import the subkey, you want them to import the secret key, with the minimum of keymaterial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.