36

An OpenPGP encrypted file will include the key ID of the intended recipient's public encryption key, as explained in this question.

Is there any way to remove that information from the resulting encrypted file? Does gpg provide an option to not include that information?

If not, what workarounds are recommended? I want to encrypt a file for a specific recipient and share it with any third party without revealing the identity of the recipient or of the sender.

(It may be assumed that the recipient's public key is widely shared and associated with the recipient's real identity.)

Community
  • 1
Flimm
  • 1,230
  • 3
  • 13
  • 22

4 Answers4

35

Use the -R (or --hidden-recipient) flag in gpg to do this. More details in this answer.

Community
  • 1
kbs
  • 801
  • 6
  • 7
  • 3
    You, sir/ma'am, are a genius. I can't believe I didn't spot this. – Flimm Jan 22 '13 at 18:53
  • Will it still show an anonymous recipient? Is it possible to hide it completely? – gauteh Jul 13 '16 at 14:14
  • @gauteh, why would you want to hide something that everyone knows is there? If it's encrypted, of course it's encrypted with a key, and that key has an owner. That's a fact that doesn't change whether you know the recipient or not. What is your proposed use case? I can't see any scenario where this makes sense. – Jürgen A. Erhard Oct 06 '21 at 17:42
  • @JürgenA.Erhard: You do not want the recipients to know about each other. Equivalent to using the BCC field in email rather than To or CC. With GPG you will still know how many other recipients there are, but not who they are. – gauteh Oct 07 '21 at 07:38
19

Several options exist in gpg. Note that you can use all of these in your gpg.conf file to set them permanently (by ommitting the '--' in front of the long options, but note that --try-secret-key is an option only available in version 2.1beta1+, which has been in beta for 3 years now. The documentation was generated by error I think as most people won't have this option available):

--hidden-recipient name

   -R     Encrypt for user ID name, but hide the key ID of this user's key. This option   
          helps to hide the receiver  of  the  message and  is  a limited countermeasure
          against traffic analysis. If this option or --recipient is not specified, 
          GnuPG asks for the user ID unless --default-recipient is given.


--hidden-encrypt-to name
          Same as --hidden-recipient but this one is intended for use in the options file
          and may be used with your own user-id as a hidden  "encrypt-to-self".  These
          keys are only used when there are other recipients given either by use of 
          --recipient or by the asked user id.  No trust checking is performed for these user
          ids and even disabled keys can be used.


--throw-keyids

   --no-throw-keyids
          Do not put the recipient key IDs into encrypted messages. This helps to hide the 
          receivers of the message and is a limited countermeasure against traffic analysis. 
          ([Using a little social engineering anyone who is able to decrypt the message can
          check whether one of the other recipients is the one he suspects.])  On the 
          receiving side, it may slow down  the  decryption  process  because  all  
          available  secret keys must be tried.  --no-throw-keyids disables this option. This 
          option is essentially the same as using --hidden-recipient for all recipients.

On the receiving end... Note that it can be particularly annoying if you have many private keys because gpg will prompt you for your passphrase for each one until a working one is found. To cycle fast through the prompts, just press enter for the wrong keys, gpg shouldn't prompt you more than once per key like this.

There are a number of techniques possible for receiving software (like mail clients) to alleviate this problem. The most practical I know of is to generate a temporary keyring with the key(s) expected to be the anonymous recipient (eg. the email address you received the mail on). On failure with that/those keys, gpg should be called again without changing the keyrings in order to try all the users secret keys. The commands are as:

gpg --export-secret-keys <key(s)> > tmp_keyring
gpg --decrypt --no-default-keyring --secret-keyring tmp_keyring <...>
On failure:
gpg --decrypt <...>

Here are the options:

--try-secret-key name
          For  hidden  recipients  GPG needs to know the keys to use for trial decryption.
          The key set with --default-key is always tried first, but this is often not 
          sufficient.  This option allows to set more keys  to  be  used  for  trial
          decryption. Although any valid user-id specification may be used for name it makes 
          sense to use at least the long keyid to avoid ambiguities.  Note that gpg-agent 
          might pop up a pinentry for a lot keys to do the trial decryption.  If you want 
          to stop  all further trial decryption you may use close-window button instead 
          of the cancel button.

   --try-all-secrets
          Don't  look  at the key ID as stored in the message but try all secret keys in turn 
          to find the right decryption key. This option forces the behaviour as used by 
          anonymous recipients (created by using --throw-keyids  or  --hidden-recipient)
          and might come handy in case where an encrypted message contains a bogus key ID.

   --skip-hidden-recipients

   --no-skip-hidden-recipients
          During decryption skip all anonymous recipients.  This option helps in the case that 
          people use the hidden recipients feature to hide there own encrypt-to key from 
          others.  If oneself has many secret keys this may lead  to  a  major  annoyance
          because all keys are tried in turn to decrypt something which was not really 
          intended for it.  The drawback of this option is that it is currently not possible 
          to decrypt a message which includes real anonymous recipients.

If you are interested in privacy another option might interest you. It is literally useless and downright bad for your privacy to emit your OS and software version when sending emails:

   --emit-version

   --no-emit-version
          Force inclusion of the version string in ASCII armored output.  If given once only 
          the name of the program and  the  major number  is  emitted  (default), given twice 
          the minor is also emitted, given triple the micro is added, and given quad an
          operating system identification is also emitted.  --no-emit-version disables 
          the version line.

For a general overview of gpg best practices for security and privacy, check out this primer by riseup labs.

  • This should be the accepted answer. The addition options are all pertinent. – eduncan911 May 04 '17 at 16:52
  • Please be aware that it is still possible to recover the true recipient: https://crypto.stackexchange.com/questions/51555/multi-party-anonymous-key-distribution/51561#51561 https://security.stackexchange.com/questions/186306/in-openpgp-when-encrypting-with-public-key-is-it-possible-to-not-include-the/186310#186310 – sanmai Apr 21 '19 at 09:57
3

I'm not sure if you can strip that information with any particular program, but I don't see why it would cause any issues. As for a work around, the recipient could sign a new public key with their private key, encrypt the new public key with the sender's public key, send the new public key to the sender which the sender could then use for the transmission. In this way, the new "session" public key is never revealed to the world and there would be no way to link it back to the recipient.

It is worth noting that it is still possible for someone to know that the recipient talked to the sender though, so if you are trying to prevent anyone from knowing about either half of the conversation even occurring then this wouldn't work.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • Thanks for your answer. I've edited the question to make it clear that I don't want any information about the recipient *or* the sender to leak. If an attacker found the encrypted message on a USB stick, they should not gain any information from it. – Flimm Dec 10 '12 at 18:13
  • @Flimm - Well, as long as the initial exchange of anonymous public keys is not compromised, then a USB stick with the other messages would not leak any information. This sounds like it is really a key distribution problem since in order to still verify sender and recipient while making sure that nobody else can, you need a secure method to exchange the keys anonymously. I'm not sure what the security requirements are for your use case. – AJ Henderson Dec 10 '12 at 20:36
  • Isn't there a way using PGP that you can publicly distribute your public keys, while hiding who the intended recipient is of an encrypted message? I don't see a reason why this couldn't be possible in theory. Why doesn't GPG simply omit the recipient's key ID in plain-text in the created encrypted message? – Flimm Dec 10 '12 at 20:43
  • @Flimm - it may well be possible, but I think that would be implementation specific. The only reason I think it is normally included is for ease of decryption when multiple keys are on the recipient's key ring. Normally, leaking who a message is for isn't considered a significant threat and having to try every key you have to determine which is valid is a bit of a pain. – AJ Henderson Dec 10 '12 at 20:50
1

As a workaround, the recipient could prepare a new public key (maybe using very short expiration dates) and have that file be encrypted with this one. So even though it will still be possible to determine for which key the file is encrypted, that key is new and thus not associated with anyone.

Vucar Timnärakrul
  • 121
  • 4
  • How would the recipient distribute the public key to to the sender without making it known to the attacker? Public keys are meant to be publicly distributed. – Flimm Dec 09 '12 at 12:37
  • The new public key could be encrypted, with the private key of the sender. Of course, that still leaves *some* degree of association between the two parties; I doubt if that can be avoided without some sort of physical communication… – Vucar Timnärakrul Dec 09 '12 at 13:36