Add padding to GPG-encrypted messages and files

[zenmonkeykstop]

Description

(Following on from a chat with @evilaliv3...)

RFC9580-compliant GPG-encrypted files can include padding as part of the encryption process to make it harder to infer the length of plaintext from the ciphertext. Sequoia 2.* added support for RFC9580, so if we upgraded the version used by redwood adding padding to files and messages would be pretty straightforward.

One downside might be lack of broader support for RFC950 - it would be necessary to verify that other GPG applications used in the SD workflow could support it, and that older RFC4880 messages still worked:

• Kleopatra on tails
• GPG2 on Qubes (in sd-gpg)
• Electron app (currently planned to use OpenPGP.js)

(A lazier RFC4880-compliant approach would be to pad all messages (not files) to the max message length, to make them indistinguishable.)

(Looks like this was also considered way back with #7002

How will this impact SecureDrop users?

• no UX impact, apart from possibly a minor impact on message download times.

How would this affect SecureDrop's threat model?

• it would be a further mitigation for either server seizure or network traffic analysis,

[legoktm]

#7002 is the pre-RFC9580 version of this suggestion.

[zenmonkeykstop]

#7002 is the pre-RFC9580 version of this suggestion.

Yup, looks like the schism is still in effect too so chances are this is still blocked on gnupg in sd-gpg.