Sharing a PGP Private Key

Question

I read often that you should not share a PGP private key. I understand that and it makes sense. If someone has my private key (and manages to obtain the password for it), I can be impersonated.

But are there usecases where sharing a private key is considered okay? Considering two scenarios, where we have a shared directory with only lax management of access rights to it:

1. Encrypting the file with a public key and sharing the (password protected) private key dedicated for this purpose
2. Encrypting the file with AES-256 (e.g. using 7-zip) and sharing the password

Having only these two options, I would consider the first one to be more secure.

Is there a better way to implement this access control if only the described infrastructure is available? I know both options are not ideal and also do not allow to revoke access for a specific user.

Answer 1

You tagged this question as pgp and mention PGP in the question title, so I am assuming that this is what you are asking about.

PGP (PGP, OpenPGP, GnuPG) has supported encrypting a file asymmetrically to several recipient keys for like forever (certainly for the last decade; probably for far longer).

For command-line GnuPG, the simple way to do this is to give multiple --recipient (-r) command line arguments listing the different keys. Other implementations will have some other way of accomplishing the same result.

Each recipient share their public key and controls their own corresponding private key, so no private key sharing is involved.

Technically, this creates multiple public-key encrypted session key packets in the resulting ciphertext file, each encrypted with a different recipient public key. This typically requires a few tens of bytes per recipient key, so the overhead can be considered minimal unless the number of recipient keys is huge.

Answer 2

In the first case you mention, why would you not encrypt it with the private key and then share the public key?

There's a reason it's called the "private" key. Once you no longer have complete control of the private key, consider it public. You cannot control what someone else does with that private key, so they could impersonate you, publish it on the web, give it away, or do anything else that they want with it. In other words, you are right that someone can impersonate you. Once that has happened, that bell can't be un-rung.

If there's a concern with lax management of a shared directory, I'd suggest taking up that issue separately rather than working around the issue by sharing a private key.

At least with the second solution, you may have a weaker overall security solution, but it's dedicated to this issue.

Answer 3

A private key is supposed to be private (either to an individual or to a group) and may have to be shared within that group.

While there are implications when sharing a private key, there may be use cases where this is useful, for example an email address that represents a group rather than an individual.

As long as the implications are known and respected, you can share the private key in whatever secure way you deem reasonable.

When choosing a strong input for the key derivation function, i.e. have the key protected by a good passphrase such that the encryption scheme encrypting the key is at its best security, you may publicly disclose the encrypted key and share the pass phrase on a (secure!) channel. After all, an attacker that can break AES may very well also just break RSA, compromising your key with just knowing the public key.

Answer 4

You could consider to have multiple versions of the files encrypted by each of the participant public keys.

If the file is too big, you could encrypt it with a temporary symmetric key and put multiple version of the key encrypted with each public keys.