I've seen many instances where a company or organization generates and uses a PGP keypair for a team or group of people. Most likely they all have a copy of the private and public keys on their individual machines or sign on to central server and use the gpg utility there (all knowing the shared secret key password).

What happens when one member of the team leaves the company? What if they go rogue upon departure? Assume that they copied the secret/key to their personal USB thumbdrive before you revoked access to the central server or watched them delete their keypair.

It would be extremely inconvenient and impractical to revoke and reissue the "team" PGP key every time someone left the company (image a team of 10+ people).

What do companies currently do? Do they just ignore the possibility an ex-team member will act with malice?

For a realistic scenario, let's talk explicitly about a [email protected] mailbox with PGP key "Example Inc. Security Team" <[email protected]> (0xAAF00F00) where Bob, Alice, and Charlie (the team) have access to the mailbox, and PGP public/private keypair.

The mailbox and PGP key is for receiving reports of high-severity security vulnerabilities to Example Inc. and the team leverages encryption and message signing for correspondence with security researchers.

2 Answers 2


The setup you described is not ideal. It would be better to implement a certificate authority and setup everyone with their own private-public keypairs. There are schemes where you would then grant access to a shared resource using ACLs at the application level or by having a symmetric key which is used for access and encrypted with each person's public key. You would then change these shared keys for any affected resource when someone leaves.

For a realistic scenario, let's talk explicitly about a [email protected] mailbox with PGP key "Example Inc. Security Team" (0xAAF00F00) where Bob, Alice, and Charlie (the team) have access to the mailbox, and PGP public/private keypair.

In your scenario, the shared keypair is not relevant. Even if they have their own keys, once its decrypted they have it. If you have an encrypted document and you have the key, and you leave with both it would not matter either because unlike with a paper document in a filing cabinet its trivial to make copies. If I leave the company, why do I still have access to the mailserver? If I do not have access and I still have the decryption key, I would have to break in and presumably defeat some other layers of security to even gain access to first decrypt it.

I would not recommend sharing the mailbox like this in general because there would be no accountability for who sent out an email or who read an email because they are technically sharing the identity. Better to have the message fed into a system with RBAC. Maybe you would them implement an HSM solution combined with certs/keys for access to the system and the decryption is owned by the system not the users.

Security needs to be applied in layers. Do not permit the thumb drives, make them log in through Citrix with all printing and copy and paste disabled, make it so the only way to get a copy of the data is by taking a picture (you could physically prohibit cell phones and cameras). The concern here is really the ability to copy digital data. You could implement some DRM based solutions potentially to address this as well, but DRM can be defeated and it doesn't prevent copying or screen caping.


There is no way to distribute the key to everyone and at the same time being able to withdraw access to anybody of the team.

Possible solutions for encryption:

  • The sender encrypts to all members of your team, each having his private key.
  • If you need to have a single key, have a central "decryption service" where all team members can put stuff to decrypt it, the key stays on the server.

    You might also decrypt it on the server and sign and mail it again to all other team members.

  • Split up the key in chunks, so only n members of the team can decrypt the content together. No single person can use the key on his own. Think about it as a kind of RAID 5/6.

    There's even a flag you can set in the OpenPGP standard for this, I'm not sure if there are any implementations out there.

Possible solutions for signing:

  • Have some member of the group (for example, the team leader) act as a kind of certificate authority and make the other side put trust on him. He will sign all other team members. The other side is now able to verify all signatures of your team.
  • Have a central "signing service" like we had for encryption.
  • Distribute subkeys of the primary key. You can revoke each of those, but the primary key, UIDs and thus incoming trust stay the same.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .