Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 6 down vote favorite
2

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.)

share|improve this question

3 Answers

up vote 4 down vote accepted

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

share|improve this answer
You, sir/ma'am, are a genius. I can't believe I didn't spot this. – Flimm Jan 22 at 18:53
up vote 3 down vote

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.

share|improve this answer
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
up vote 1 down vote

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.

share|improve this answer
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 9 '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… – Kevin Dec 9 '12 at 13:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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