Hi everyone, thanks for everyone's very helpful feedback. See inline.
Shawn K. Quinn wrote: > On 08/29/2017 02:14 AM, s7r wrote: >> Hi Phil, >> Thanks - this is indeed _very_ useful for my use case. I don't think the >> second part is a problem since I can particularly request to not set the >> `throw-keyids` option, but let's say metadata becomes a problem at a >> given point and we decide to use this option, can I tell which recipient >> 'should' be able to decrypt a message based only on the encrypted >> message format if the `throw-keyids` option was used? > > No, that's the whole point of throw-keyids. All you're supposed to be > able to tell when using that option, is that none of your keys will > decrypt the message, so it's not for you. > > Ok, understood, last thing: at least can I learn just by looking at the cipher text that `throw-keyids` option was used and choose not to further transmit that message and at least warn the sender that he should double check and confirm one more time for safety reasons? There is a single threat model: I am trying hard to prevent accidental usage in an app where a message encrypted for a different recipient ends up to the wrong person, no matter the recipient that actually gets the ciphertext by mistake has absolutely no real use with it because he won't be able to decrypt it -- the downside and loss is at sender side for thinking the message was sent to someone else and further action is expected.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
