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

[s7r]

Robert J. Hansen wrote:
>> 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.
> 
> Sure, but this is a heuristic, not a formal verification.  A useful
> heuristic, absolutely, but this is still at the level of "let's look at
> the packets to glean publicly available data" -- whereas message
> sanitization and verification would require access to the content of the
> message.
> 
> Part of this is, I think, the OP is being a little handwavy with the
> idea of verification/sanitization.  If what you're checking is dependent
> in any way on the cleartext, then you're screwed.  And if what you're
> checking is dependent on the ciphertext, you're not really dealing with
> the message at all, but the container it's packaged into.
> 

Yes, what needs to be checked is dependent on the cipher text. Only if
the message has all the packets and theoretically can be decrypted (if
the recipient has the private key). It does not matter if the cleartext
makes sense to the recipient or not.

"look to see which keyids are given as hints in the outermost layer" --
not sure I understand here. I am trying to do a check that is natively
supported by gnupg.

-------------- 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/99aef5fc/attachment.sig>