Trusting other keys a message was encrypted to

vedaal at vedaal at
Fri Nov 6 16:46:21 CET 2015

On 11/6/2015 at 10:11 AM, "MFPA"  wrote:
While writing in the "TOFU for GnuPG" thread it occurred to me that
GnuPG does not look at whether we "trust" the other keys to which an
incoming message was encrypted.

Wouldn't it be reasonable to also look at whether we "trust" other
keys that are seen to be a party to the conversation?


GnuPG already does.

It will ask for each key that you want to encrypt to, if you haven't
trusted it, and ask if you really want to do this.
Assuming that you trusted the person who sent it to you, then it's
reasonable "for that person' to encrypt to other keys that that person
You should encrypt only to keys you trust, and if they trust someone
else's keys they can encrypt your reply to them.

This will defeat an interesting man in the middle attack:
Suppose Alice wants to encrypt to Bob, and Eve, and Rumplestiltsken,
and sends a signed and encrypted message to Bob showing that it was
also encrypted to Rumplestiltsken, whom Bob does not know.

Mallory can intercept this mail, remove the ESK packet for
Rumplestiltsken, make his own fake Rumplestiltsken key, and encrypt
'any' session key to it, and then add the ESK packet, and make a new
checksum and replace it, and send on the message.

Since you are not able to encrypt either the real or the fake
Rumplestiltsken key, you have no way of knowing if the session key is
genuine or not in that packet.

Now if you routinely encrypt to all the keys when you reply, then
Mallory can decrypt the message.

A prudent workaround when encrypting to multiple keys, is to mention
in the signed plaintext which keys and fingerprints are being
encrypted to, 
and then if there is some pressing reason to multiple encrypt, then
the receiver who trusts the sender's *trust* of the other keys, can go
ahead and multliple encrypt the reply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151106/cf08a65d/attachment.html>

More information about the Gnupg-users mailing list