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

s7r s7r at
Tue Aug 29 09:14:35 CEST 2017

Phil Pennock wrote:
> On 2017-08-28 at 19:05 -0400, Rob J Hansen wrote:
>>> 1. Is it possible, when transporting a message from Alice to Bob,
>>> without holding any of their private keys, to do the following checks:
>>> - verify the integrity of the message and make sure it is sanitized and
>>> Bob can decrypt it with his private key;
>> No.  You can check the format of the message and ensure it's not
>> mangled, but that's about it.  A loose proof of this follows:
> Well, you can go one step further.  Unless the sender is throwing the
> key ids, you can look to see which keyids are given as hints in the
> outermost layer, to see which people are expected to be able to decrypt
> it.
> In `gpg --list-packets` output, that will be the `:pubkey enc packet:`
> items.
>     GNUPGHOME=/nonexistent gpg --batch --list-packets < "${INPUT_FN:?}"
> It won't confirm that Bob _can_ decrypt it, since that goes into a lot
> of assumptions about competence, not lost keys, possession of devices,
> whatever.  But in normal use, it'll tell you if Bob should be able to
> decrypt it.
> Privacy-sensitive environments concerned about metadata analysis will
> set the `throw-keyids` option in their config and that would prevent
> this.
> -Phil

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?

-------------- 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/20170829/48c07696/attachment.sig>

More information about the Gnupg-users mailing list