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 trusts. 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. vedaal
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users