Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Comments on Can a malicious party add false recipients (who are listed but can't really decrypt) to an encrypted GPG message?

Post

Can a malicious party add false recipients (who are listed but can't really decrypt) to an encrypted GPG message?

+3
−0

In gpg(1), one normally adds recipients of an encrypted message with --recipient. Those recipients will be able to decrypt the message, and their key ID will appear unencrypted, so anyone will know that they are able to decrypt it.

gpg(1) also allows adding hidden recipients, with --hidden-recipient. Those recipients will be able to decrypt the message, but a third party won't know that they are able to decrypt it.

I wonder if a malicious party would be able to craft an encrypted message, and falsely claim that someone else would be able to decrypt it (not necessarily with gpg(1), I wonder if one can craft a tool that creates a message that gpg(1) will interpret as valid), listing it as a recipient.

Is that possible?

Related: https://stackoverflow.com/questions/5877969/how-do-i-list-information-for-a-gnupg-encrypted-message

Related: https://github.com/neomutt/neomutt/pull/4221

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

What malice? (4 comments)
What malice?
Karl Knechtel‭ wrote 7 months ago

It's not really clear to me what harm could actually be caused by doing this, if it's possible. Could you describe a more detailed scenario of concern in the question?

alx‭ wrote 7 months ago · edited 7 months ago

Let's say I send you some private message, let's say a bug report about a vulnerability.

Now, Mallory wants to read that message, and also your reply to it. He may take that message, add himself as Cc (AFAIK, the Cc field is not a protected field; see crypt_protected_headers_read in muttrc(5)), and modify the metadata of the encrypted message to add his keyID as a recipient, even when he's not able to decrypt the message.

When you receive my bug report, altered by Mallory, you'll be lead to think that I CCed him, and that I want him to be part of the conversation, and so in your reply, which will likely contain (at least part of) my original report, you will likely encrypt it for both me and Mallory and send it to both.

So, is Mallory able to modify the metadata of an encrypted message to add false recipients to it?

Skipping 1 deleted comment.

aheinlein‭ wrote 5 months ago · edited 5 months ago

The critical point of your question is, how would Mallory do this: " He may take that message, add himself as Cc". This needs to be done during encryption - if Mallory is in a position to do that, you already have a security breach. If Mallory intercepted the already encrypted message, he could do nothing useful with it.

alx‭ wrote 5 months ago

aheinlein‭

" He may take that message, add himself as Cc": By "message" here I meant a RFC822 message, that is, an email. The header of an email is sent in plain text, and a MITM can easily modify it.