If Alice encrypts a file with GnuPG software using the AES-256 mode, and sends the encrypted file over an insecure channel (like E-mail or HTTP) to Bob. Both Alice and Bob know the password, but only them.

1) What is the probability that Bob received a maliciously manipulated file that opens with the same password and is the same byte size,but assuming that only Alice and Bob know the password?

So what I am asking is that how likely it is that an adversary can recreate a similar sized file with let's say a malware in it, which would open with the same password, but them not knowing the password.

I assume here that the AES ciphertext is like a random oracle in theory so the bits would look random thus the attacker would have no way of replacing the plaintext of it with a malwared version, and create an similar sized ciphertext but without knowing the password, other than brute forcing every bit to the same output .

2) I am assuming serious brute forcing would be needed here, and there would be no easier way unless AES256 has some vulnerability. I also assume that there is a linear relationship between the increasing strenght of the password and the decreasing probability of this being possible. Would encrypting with a secret password known between 2 parties provide the same kind of authenticity as a SHA256 hash? In other words would it be just as hard to modify the ciphertext as to break SHA256 in this instance, or is AES256 more malleable?

  • 1
    $\begingroup$ The quick answer is that the OpenPGP protocol—of which GnuPG is an implementation—does not provide any serious password-based or other symmetric-key authentication. There's the kludgey ‘modification detection code’ whose absence of intended security properties is summarized in a NON-NORMATIVE poetic monologue in RFC 4880 §5.13 ‘Sym. Encrypted Integrity Protected Data Packet (Tag 18)’ full of sound and fury and signifying nothing. Suffice it to say that the only reliable message authentication OpenPGP and GnuPG provide is digital signature. $\endgroup$ – Squeamish Ossifrage Mar 2 '18 at 18:04
  • $\begingroup$ If you want just a password-based file authenticated-encryption tool, I recommend scrypt(1), which has a very simple protocol that withstands scrutiny, does authenticated encryption, and resists brute force attacks on the password space better than anything in OpenPGP does. $\endgroup$ – Squeamish Ossifrage Mar 2 '18 at 18:06
  • $\begingroup$ @SqueamishOssifrage I think you answered the wrong question, I asked about authentication and signature in a different question. This question is about whether the OpenPGP protocol (as symmetric encryption) is strong enough to not let the ciphertext be recreated from a malicious plaintext. Basically whether the OpenPGP protocol (of the AES256 implementation) is injective or not? $\endgroup$ – cryptonerd0014 Mar 9 '18 at 18:50
  • $\begingroup$ What you are asking about—ciphertexts forged by adversaries without knowledge of the secret key/password—is precisely what authentication exists to prevent. My answer is that OpenPGP does not provide authentication for password-encrypted files. The only kind of authentication that OpenPGP provides is digital signatures. (A message encryption scheme is always injective; otherwise for each ciphertext there are multiple possible messages that could be the plaintext. This is unrelated to authentication.) $\endgroup$ – Squeamish Ossifrage Mar 9 '18 at 19:58
  • $\begingroup$ @SqueamishOssifrage I don't get it, shouldn't forging identical ciphertexts for different plaintexts would mean breaking AES256. The cipher should provide random outputs thus it would theoretically be no shorter way of breaking the ciphertext or reconstructing a malicious one without bruteforcing it, given if the plaintext contains at least 256bit of entropy, otherwise guessing that would be more efficient. $\endgroup$ – cryptonerd0014 Mar 13 '18 at 21:49

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.