If you gpg sign AND encrypt, do you sign-then-encrypt or encrypt-then-sign?
There has long been a (very strong) argument for mac-then-encrypt being worse than encrypt-then-mac (see e.g. padding oracle attacks), with eventually authenticated encryption (an effective "mac AND encrypt") eventually seen as even better than both; at least in the context of TLS and similar protocols.
For message signing however, you really want to keep the transferrability property of the signature.
it occurs to me you could sign-then-encrypt-then-sign if ciphertext malleability concerns you. unless i missed something.
> sign then encrypt
it probably wasn't clear, but i was actually asking which of the two gpg does if you --sign and --encrypt, so are you answering here?
> But u leave uc valuable key noise if u sign again
I don't understand 'uc' there, but .. that's an interesting point to raise. On one hand, it's at least true in abstract, every +1 signature can leak something, if the scheme is sound that should be negligible.
Another consideration: signing ciphertext makes it non-repudiable.
@waxwing uc under circumstances
i assumed --armor sign and then encrypt the output is a good practice, but not sure how those parameters are interpreted if in one sweep on one cmdlline hmm lets check the source ...
@waxwing in gnupg it looks like it does
sign encrypt if u use both options.
on one cmdline. afaics
case aSignEncr:
cmdname="--sign --encrypt";
break;
@waxwing sign then encrypt, but why sign again the --armor output?
But u leave uc valuable key noise if u sign again, that could help to get faster break the encrypt that protect ur sign or am i here missing something?