# Probability of getting different plaintext with different key

What is the probability that an AES encrypted file, using a wrong password, gets decrypted to something different than the plaintext, but which could still be likely to be interpreted an the true plaintext by the attacker? Example:

1. John Doe encrypts a TXT file which only contains the following sentence: "Tomorrow we are going to throw eggs at the president". Encrypted with AES-256-CBC, key derived from a 128-bit password.
2. How many other passwords, other than the real one, are going to produce a plaintext containing a meaningful English sentence?
3. Would using AES-GCM avoid the problem and make sure that the real password can be distinguished from other plausible passwords that happen to produce a plaintext?

Is it possible to calculate an estimate, or a range of probabilities? I thought of this question while wondering: what's the use of huge keys or passwords, if among those keys there are some that might produce an even more compromising plaintext than the real one? Of course I would suppose the probability of encrypting a picture (say, several KB) with a password and getting a different picture after decryption is extremely low, but when I think of smaller files (like the 52-byte text in the example above) I'm not so sure.

• WRT 2, Decrypting a cyphertext with a random key will produce a result that is indistinguishable from random text. If you do this many times (using a different random key each time), a large number of the results will be invalid due to padding errors. But, taking the results that have valid padding, each of these will contain random text. So, your question is equivalent to asking 'what is the likelihood of getting a valid English sentence, when constructing a string from random characters'? As you said, this decreases exponentially with length, but even at 50, it would seem highly unlikely. Commented Jul 6, 2022 at 11:36

We can roughly consider the output of a cryptographic function as random. The questions is a monumental calculation as stated (the ratio of valid sentences to junk for a given collection of bytes). Instead I will pose it as follows:

3.123*10^7 = number of AES operations per second at 1GB/s

(52/256)^x = odds that a given plaintext starts with x alpha characters

(52/256)^x * 3.123*10^7 = Likelihood of finding a plaintext that starts with x apha bytes at the start.

Somewhere around X=13 it seems like about once per hour one would find such a plaintext. Now the odds that those 13 characters are a valid sentence would determine how many hours one would have to wait to see what you ask for.

Would using AES-GCM avoid the problem and make sure that the real password can be distinguished from other plausible passwords that happen to produce a plaintext?

Probably, yes. It is of course possible in the infinite collection of cyphertexts and infinite-seeming collection of AES keys that there exists two valid looking plaintexts that both have the same MAC for even the same AAD. But if we thought the first question was merely unlikely, this would be monumentally unlikely.