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.
@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?
> 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
@waxwing Encrypt-then-sign has the disadvantage that someone could replace the signature with their own and trick the recipient into thinking that the secret message came from them. Ciphertext malleability would be solved by the proposed AEAD modes like EAX in rfc4880bis.
@waxwing In symmetric crypto encrypt-then-mac is fine because you already know who the sender is, as you share a secret key with them.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!