Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)
s7r
s7r at sky-ip.org
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