decryption outputs to stdout before verification

[Tennyson T Bardwell]

Werner,

Thank you, that was very helpful.

> Sure, gpg is a Unix tool and as such used in pipeline to process huge
> amounts of data.

> Right.  Before you further process the data you should verify it.  

> You can do that with --assert-signer like:

> I have not read that article but a good mail client should indicate
> what part of the forwarded mail has been signed.

I certainly missed `-assert-signer`. And I am starting to get
comfortable with the trade-offs that piping can have, as well as the
requirement to start emails with "Hello <recipient>" to prevent
surreptitious forwarding (assuming S/MIME doesn't verify email headers
like "to").

>> I often see it recommended to sign messages before encrypting to ensure
>> integrity (and, as a byproduct, authentication). It seems that this was
>> so crucial that MDCs are now enabled by default. My understanding is
>> that MDCs provide integrity guarantees without signing. It seems that a
>
> An MDC implementes authenticated encryption (AE or AEAD) and for certain
> use cases it is better to have integrity.  In the old PGP days we always
> said, that signing is enough.  But for some uses cases authenticated
> encryption is needed.

I think that I misunderstood the gaps between integrity, authentication,
and signing (tamper-detection vs knowledge of some key vs
non-repudiation).

It seems like the key exchange used to produce the shared secret for MAC
might determine if the message, taken as a whole, is authenticated or
merely integrity protected. If a random key were created and encrypted
to the recipient's public key, then the message would (for all intensive
purposes) be only integrity protected. The message could be intercept
and replaced (in its entirety) without detection. I assume that saying
"MAC" implies that the shared secret was somehow authenticated, such as
with DH. I assume that some standard (perhaps CMS) establishes this.

For my purposes, I mostly just want my messages to be resistant to
surreptitious forwarding. I know that S/MIME can perform signing.
Since I'm not sure what associated data is put into S/MIME, it seems
like the safest bet would be to simply start emails with "Hello
<recipient>". I assume that a timestamp is added to the signature, so
that should take care of contextualizing the signed message.

Warmly,
Tennyson
🌸