5

Lets say I have a key - k, and plain text P. I then encrypt P with AES using key k:

C = AES_k(P)

Now lets say I have another plain text that I chose - P*.This plain text has nothing to do with P, I choose it to be whatever I want it to be.

Is it possible to find a key - k*, so that when I decrypt C with k* I will get P* ?

Meaning: D_k*( AES_k(P) ) = P*

qowpr
  • 51
  • 1
  • 2
  • Are you actually asking whether it's possible to find the key, or more simply, whether such a key exists? – Oliver Charlesworth Feb 13 '11 at 15:30
  • Both - I'm interested in whether or not such a key exists, and then if it does if there's any efficient way to produce it (as going through all possible options trying to find it isn't feasible). – qowpr Feb 13 '11 at 15:35

4 Answers4

9

I don't think the key will necessarily exist. A key defines a permutation over all possible values of a block. With a 128-bit block size, there are (2^128)! possible permutations. With a 256-bit key, there are 2^256 possible keys. That's considerably less than the number of permutations, and so not every permutation can be specified. I think - although I certainly cannot prove, or even argue - that this means that there may not be a specifiable permutation which maps your chosen second plaintext to the ciphertext.

If such a permutation does exist, I think it would be very hard to find. If it was easy, known plaintext attacks on the cipher would be trivial.

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
  • I agree that the key does not necessarily exist, but I think it is likely to exist for AES-128, there are likely 2^64 such keys for AES-192, and likely 2^128 such keys for AES-256. He is only constraining one entry of the resulting permutation. – President James K. Polk Feb 13 '11 at 22:43
  • @GregS It's not at all likely to exist - the number of possible plaintexts of a reasonable size is vastly, vastly larger than the number of keys. – Nick Johnson Feb 14 '11 at 00:41
  • @Nick Johnson: I was assuming it was a single block, as was this answer. The probability of a single random key mapping P* to C is about 2^(-128), and the rest follows. – President James K. Polk Feb 14 '11 at 00:52
  • @Nick Johnson: I assume you mean the number of permutations, not the number of blocks. But @GregS is right, since we only care about one point in the permutation, the odds that it exists are much better than I had suggested. You still can't find the key for it, though! – Tom Anderson Feb 14 '11 at 13:38
  • @Tom Anderson: I believe you meant to say "128! possible permutations." – Harlan Jun 26 '16 at 23:17
  • @Harlan: I don't think so. An N-bit block has 2^N distinct values. A set of M distinct values has M! permutations. So there are (2^N)! permutations over the values of an N-bit block. – Tom Anderson Jun 27 '16 at 16:51
  • @Tom Anderson: Thanks. I thought you were possibly referring to the number of ways to permute the 128 bits in a block (~3.9 x 10^215). However, it's not clear why you are considering the number of ways to arrange all of the 2^128 distinct values - a gargantuan number with something like 10^40 zeros in the exponent. – Harlan Jun 28 '16 at 21:22
  • @Harlan: Because that's the number of possible ways to encipher 128-bit blocks. A cipher is a function that maps an N-bit input to an N-bit output; it has to [map every input to a unique output](https://en.wikipedia.org/wiki/Bijection), so that it's reversible. That amounts to a permutation - if you run through the 2^N possible values of the N-bit block from 0 to 2^N-1, encipher each one, and write the results in a list, then you have 2^N values, all different, and so you have a permutation of the values you started with. Therefore, there are (2^N)! possible different ciphers. – Tom Anderson Jun 29 '16 at 10:55
4

I assume here that your plaintexts and ciphertexts P, P* and C are all 128-bit blocks.

If your keys k and k* have 128-bit length (i.e. you are using AES-128), then, with probability about 36.8%, there is no solution: more formally, if you consider the set of all possible values for C and P* (2256 combinations), then for about e-1 of them there is no k* such that AES_k*(P*) = C.

This follows from the idea that, for a given value of P*, the function which transforms k* into AES_k*(P*) should behave as a random function, and a random function from a set of size N to a set of identical size N has average coverage of 1-e-1 of the destination set. Here, for a given P*, there are about 63.2% of 128-bit words which are possible outputs of AES encryption of P* with a 128-bit key.

On the other hand, if you allow k* to be wider (AES also accepts 192-bit and 256-bit keys) then there should be a great many solutions k* to your equation.

Anyway, actually finding k* (even a 192-bit or 256-bit k*) should be infeasible, with work factor close to 2128 operations. Being able to find k* with less work than that could be viewed as a structural flaw in AES. Knowledge of P and k helps in no way: for the given 128-bit ciphertext C, it is easy to find matching pairs (P, k).

Note: if you take AES and swap the roles of the plaintext and the key, then you get a crude emulation of a hash function with limited input, and 128-bit output. What you are asking for is the feasibility of a preimage attack on that hash function.

Thomas Pornin
  • 72,986
  • 14
  • 147
  • 189
1

This should not be possible for any plaintext that you choose. Being able to decrypt a ciphertext to arbitrary plaintext would imply something known as perfect security (or perfect secrecy).

For example, if I have cipher ADGWTX and I know that it is encrypted using simple XOR and a 6 letter key, I still cannot break this without more informaion about the key. Because one key will give me ESCAPE while another key will give me ATTACK.

Perfect security is a feature of the "one-time pad" (http://en.wikipedia.org/wiki/One-time_pad), but not AES.

irritate
  • 7,350
  • 1
  • 17
  • 11
1

It is possible to get k* and decrypt C to get plaintext P*, but only by decrypting it with another type of cipher, like perhaps vernam cipher.

you can get k* such that D_k*( AES_k(P) ) produces your P*.

you just do: P* ^ C to get your k* then if you decrypt: k* ^ C you get P* (assuming both C and P* are of equal size)

but if the size of your P* is smaller than C, then it will produce a repetitive P*

^ : bitwise XOR

Im not sure if that's what you want, you didn't mention you want to decrypt it using AES also.

user668726
  • 11
  • 2