Trusting other keys a message was encrypted to

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Friday 6 November 2015 at 3:46:21 PM, in
<mid:20151106154621.B1BD6202BF at smtp.hushmail.com>, vedaal at nym.hush.com
wrote:




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


In that case, there must be some option or setting I have missed.



When decrypting incoming messages that were encrypted to multiple
keys, for keys other than my own GnuPG tells me the key-id and a few
other pieces of information such as size and algorithm:-

   :pubkey enc packet: version 3, algo 1, keyid 0123456789012345
        data: [2047 bits]
   # off=271 ctb=85 tag=1 hlen=3 plen=524



GnuPG also tells me (for keys not on my keyring):-

    gpg: encrypted with RSA key, ID 0x0123456789012345



Or if the key is on my keyring, GnuPG adds the primary key this
encryption key is a subkey of, creation date and user-id:-

gpg: using subkey 0x0123456789012345 instead of primary key
0x5432109876543210
gpg: encrypted with 2048-bit RSA key, ID 0x0123456789012345, created
20/01/2015
      "Bob Alice Mallory"



As far as I know, none of that says whether GnuPG thinks I "trust"
the key. Or am I missing something?



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

I know. My original post included the line "GnuPG looks at whether we
"trust" keys we are about to encrypt to". (-;



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

I'll partially go along with that. It was reasonable for the sender to
encrypt to those keys because the sender "trusts" them; fair enough.
But that doesn't address my question of "Is it reasonable for the
recipient to want to check whether or not *they* "trust" the other
keys to which the sender encrypted the message?" or my assertion that
GnuPG does not perform this check.



> You
> should encrypt only to keys you trust, and if they
> trust someone else's keys they can encrypt your reply
> to them.

Sound advice.



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

Some of the detail there is beyond me, but I think I get the gist.
Presumably, the packets Mallory is tampering with are not covered by
the message signature?



> Since you are not able to decrypt 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.

OK. Doesn't that apply to all keys for which I don't have the secret
part? Wouldn't that mean any key shown on the message's encryption
list is potentially suspicious, except my own (and presumably the
sender's, so long as it was used to sign the message)?



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

For me, GnuPG would flag up Mallory's key if I had it, as you stated
above. I may tell it to go ahead, or may not. If doing it in my email
client, it would simply refuse to encrypt to an "invalid" key, and I
would have to look into which it was.



> 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

The recipient might already "trust" some of the other recipient keys
themself without having to rely on "trusting" the sender's "trust". Or
they may know a reason not to "trust" one of the keys the sender was
OK with. Especially if the latter applies, wouldn't it be better to
check this on receipt of the message, rather than only if sending a
reply?




- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Nothing a Pan-Galactic Gargle Blaster won't cure!
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJWPR29XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwyPkH+wUb5oL7B4pVBJM02lEzO+Jb
dFRgcxHBmWmgv4uGX9d5O9tN1pxVPDGQRDW7W6ZBcB22+bQsyoUwkwPndBo4z+qj
vCU9HEq5V1DzkhiU4/8YQBx8s09IufOrLGIz4PkYtVcUyrbSXFKXi2gPCVbttsEi
U8LjtYGZPvm4wale2FAML4LlKf0XRacKAUYcvVkviPnZlCu7HGEZ9IgFeEoXr/l3
/ZHjB/lXDov4hlYwuLHZ51lAupIaG9Dgo4Ct9ra3ObE4YSSQPAQ3w5of3JSkaNMB
nkmPk6MYVe766DzZddOu+ZYKVsnKw97ceyt00x2n5v5AE5N847gnC0aoZtiCa8yI
vgQBFgoAZgUCVj0dxF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OXBAQClKpNpjNyu6z/WTLnb8QoU+OGD
ZTFpKKVV47hAaa6hqgD/ZyumVTu1t/XUtNetuPym+CT79xUjSnk1xMOD8k1l7Qs=
=GKlO
-----END PGP SIGNATURE-----