Re: Trusting other keys a message was encrypted to

[Kristian Fiskerstrand]

[Sent from my iPad, as it is not a secured device there are no cryptographic 
keys on this device, meaning this message is sent without an OpenPGP signature. 
In general you should *not* rely on any information sent over such an unsecure 
channel, if you find any information controversial or un-expected send a 
response and request a signed confirmation]

> On 06 Nov 2015, at 22:37, MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> 
> wrote:
> 
> 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.
> 
> 
> 

I'm not really sure if I understand what this would protect against; The sender 
can send the information in multiple emails, even forward it unencrypted 
without you having any control of it.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Trusting other keys a message was encrypted to

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



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.

GnuPG looks at whether we "trust" keys we are about to encrypt to, and
whether we "trust" keys that signed messages we have received.
Wouldn't it be reasonable to also look at whether we "trust" other
keys that are seen to be a party to the conversation?

Of course, this could only work for keys that were not obscured by the
use of throw-keyids or hidden-recipient or hidden-encrypt-to. And if
another copy were encrypted separately, we know nothing about it.

- --
Best regards

MFPA  

Wise men learn many things from their enemies.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJWPMIaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwEcAIAJ6B95iRSPA/4KuUmbFW66x4
WzQblXacS/0YuwGM/A5U/qFxWVpt4AvhxMud6L1+HO8eHRBY+symfxAdPUsyL0Jw
ojJBIH6fMKRBhRbNc8oKyO4LqqHP1tf4tpk6xGltu/YBHEv8LSflRh3NLJpzggQ7
qV4OcGo5HOzk7Ahu1UnhCmbGh1xpCiWun2Ng8erODFDimsTbh4mA9Iw06Gjo9/Yk
R3tr9lwEiuz1uWlobnINd7sZ2fMTv2MeGLtEGmS+FIXr1bdCi9HBaDCgsmlCqdvD
9X/CboVx8pmxRHkneahTvtoYSMPwLF30Aglsi/4P82PotjM1k+QcpwkorMhqrVCI
vgQBFgoAZgUCVjzCH18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45IhNAP0UQPVdDA7SO+y89jufHPiKe8v9
QnudR30dGMdZg72/WgD+PI/MsF35tfq6Iec5pkBrEgbqHet+4ala7JFgzcG1LAc=
=WxRn
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Trusting other keys a message was encrypted to

[vedaal]

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

Re: Trusting other keys a message was encrypted to

[vedaal]

vedaal at nym.hush.com vedaal at nym.hush.com   
wrote on Fri Nov  6 16:46:21 CET 2015 :

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.

=

Sorry, typo,

meant to say  decrypt  instead of  encrypt


vedaal


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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
, ved...@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  

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

iQF8BAEBCgBmBQJWPR29XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwyPkH+wUb5oL7B4pVBJM02lEzO+Jb