Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170901/c1f7a964/attachment.sig>