1641540 - Is it necessary to add a random amount of data to the end of an encrypted message?

Status: RESOLVED WONTFIX

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert [:KaiE:]]

Let's say Thunderbird is known to usually sign OpenPGP message, and to usually include the sender's public key as an attachment.

Is it likely that the tail of the encrypted contents always has the same structure, and that the attached key is always at the same position inside the encrypted data? (Relative from the end of the data.)

If the position of the known public key is predictable inside the encrypted data, could that help an attacker to identify the decryption key?

If yes, would it be useful to randomize the position of the known attachment, by adding a random amount of padding content (e.g. whitespace) after the last inner attachment, prior to encrypting?

Comment 1

[Marcus.Brinkmann]

Ad 1) It is likely that part of the plaintext tail is predictable, but note that PGP uses compression by default, which will considerably scramble the plaintext. However, also note that PGP has structure around the plaintext, so there are other message bytes in PGP which are entirely predictable (such as the packet header), and as a user of PGP you can not avoid that.

Ad 2) Assuming PGP uses AES in CFB mode, general consensus is that (informally) the attacker can not recover any unknown information about the plaintext, irregardless of position or knowledge of surrounding plaintext bits, from the ciphertext alone.

Ad 3) I don't advise to add padding. If done insecurely, padding may enable oracle attacks which can allow an attacker to get information about the plaintext. In any case, padding would not help against known plaintext attacks (the padding itself would have structure, its length is not very random, etc).

Note that the reason known plaintext was fatal in the EFAIL attack is that CFB is malleable, and changes in the ciphertext could result in a related plaintext. The proper fix for that is integrity protection of the ciphertext, so that all related ciphertexts are dismissed as invalid and not decrypted. In PGP, it is sufficient to verify the MDC or use an AEAD mode with built in integrity check. As usual, integrity check must preceed all other format checks to disable oracle attacks. Unfortunately, PGP implementations (including gpg[1] and rnp[2]) are known to output invalid plaintext even if integrity check fails, so be aware of that and make sure that such invalid plaintext is not processed higher in the stack.

[1] https://mailarchive.ietf.org/arch/msg/openpgp/fmQgRm94jhvPLEOi0J-o7A8LpkY/
[2] https://github.com/rnpgp/rnp/issues/807

Comment 2

[u617804]

I think what You think about is the "known plaintext attack". (where in this case, even only the last part of the plaintext is guessed)
"Modern ciphers are generally resistant against purely known-plaintext attacks. One of the unfortunate exceptions was the old encryption method using in PKZIP application."
(Source: http://www.crypto-it.net/eng/attacks/known-plaintext.html)

Since You encrypt with a public key (of the recipient) which an attacker can easily get to know (e.g. from key server), the attacker could also encrypt his own generated(so known) plain text with the recipients public key and try to find the recipients private key from the encrypted result. So with asymetric encryption, You can always have the plaintext and the encrypted text. So I would be wondering if that would be a attack vector. At least, there is no need to guess where in a encrypted message is a known plaintext, if You can attack your own fully known plaintext that You encrypted.
See also
https://security.stackexchange.com/questions/42919/can-a-pgp-private-key-be-deduced-if-the-email-text-is-known

Comment 3

[u617804]

When having a public key, encrypting self chosen text with it, and by comparing the chosen clear text with the encrypted result trying to find out the corresponding private key, is called "chosen-plaintext attack" (CPA):
"Chosen-plaintext attacks become extremely important in the context of public key cryptography, where the encryption key is public and so attackers can encrypt any plaintext they choose."

I did not hear that PGP is broken, so it should be absolutely safe against CPA and the answer to Your question is "No".

Comment 4

[Magnus Melin [:mkmelin]]

Seems we should close this as wontfix?

Comment 5

[Kai Engert [:KaiE:]]

thanks everyone for your comments