15

I'm not sure if I'm calling the thing (key collisions) correctly, and that's probably why I couldn't find any information about it on Google. Still, my question is as follows. Note that I don't work with encryption right now and I'm not going to implement anything based on this knowledge; this is a purely theoretical question which I found very interesting.

Suppose that you have a key K and a plain text P. Then you use some symmetric algorithm A like one of AES variants to obtain a ciphertext C = A_encrypt(P, K). Is it possible that some key K* != K exists which can be used to get back the plain text out of the same ciphertext, i.e. P = A_decrypt(C, K*)? How it depends, if it does, on the type of the cipher (block vs stream), on the exact algorithm and on the size of the key and the size of the plain text? My intuition suggests that impossibility or, at least, improbability of such thing is the reason of existence of symmetric ciphers, but still this is not stated explicitly anywhere I could find.

What surprises me that I couldn't find anything which answers such question directly; moreover, I couldn't find anyone asking such question. All I could find are questions like this which seem to be related but not exactly the same as my question, and questions like "how to generate two keys to decipher the same data" which are somewhat opposite to my question.

Community
  • 1
Vladimir Matveev
  • 253
  • 2
  • 7

3 Answers3

20

The number of possible permutations of a block cipher are $2^n!$ where $n$ is the block size. A permutation maps all $2^n$ possible input blocks to $2^n$ possible output blocks. A key, with key space $2^k$ selects one of them. Although that's a huge number of keys, it is dwarfed by the amount of possible permutations.

Now it's not by definition impossible that the same permutation can be chosen by a key, but it is pretty unlikely. Such a key would be considered an equivalent key or - less specifically - a weak key. Many algorithms are designed to disallow weak keys. If it is possible to have the same permutation then it is likely to be present by design; you won't find one by chance alone.

Finding two keys that map a single specific plaintext to identical ciphertext or vice versa is much more likely. It depends on the block cipher details if this is anywhere near possible see this discussion on AES for more information.

For stream ciphers the question is somewhat more difficult. It probably suffices to say that the output of the stream cipher is determined by a key and an IV (sometimes fused into one, for instance in RC4). If the size of the key, IV and internal state of the stream cipher are large enough, you should not be able to find a large amount of repetition in the key streams generated for separate key / IV pairs.

It will be possible to find keys that generate small amounts of identical key streams. This is easy to see; about half of the keys should decrypt a single bit correctly. It may be impossible to determine if you'd have generated the correct plaintext though; you'd have to determine the two keys in advance.

The idea expressed above would also work for a block cipher in a streaming mode of operation such as CTR (counter mode).

These kind of questions have been asked, but they are tricky to find if you don't know the right terms - and probably even if you do.

Related is the question if algorithms contain back doors. In that case the attacker should be able to decrypt whatever the key value is though.

Deniable encryption is another somewhat related term.

Community
  • 1
Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • 6
    Note that the first paragraph is about the number of keys that are equivalent for all plaintexts. Some other key decrypting a given ciphertext back to the original plaintext is much more likely. – otus Jun 06 '16 at 12:10
15

Apparently there's at least one real-life example of a block cipher with equivalent keys:

TEA has a few weaknesses. Most notably, it suffers from equivalent keys—each key is equivalent to three others, which means that the effective key size is only 126 bits. As a result, TEA is especially bad as a cryptographic hash function. This weakness led to a method for hacking Microsoft's Xbox game console, where the cipher was used as a hash function.

(https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm)

It's a fault in the structure of the algorithm, described by Schneier:

Consider complementing the most significant bits of K0 and K1. Note that flipping the most significant bit propagates through both the addition and XOR operations, and flipping it twice cancels the modification

(https://www.schneier.com/academic/paperfiles/paper-key-schedule.pdf)

Weak or equivalent keys are not a desirable feature as a principle (even though a 126-bit key space isn't that much smaller than a 128-bit key space). This is mentioned as one of the reasons for developing TEA further into XTEA.

ilkkachu
  • 903
  • 6
  • 12
0

Assume that your block cipher reasonably approximates a pseudorandom permutation.

We decrypt your ciphertext C under all possible keys This produces 2^128 plaintexts which are randomly distributed. This is equivalent to throwing n balls into n bins for n=2^128. the chance that any particular bin is filled converges to 1-1/e for large n . We have guaranteed that one solution exists by generating C as A_encrypt(P, K) which has no effect on the distribution of all other (key, Plaintext) pairs for C. So the odds that a collision exists for all other keys is 1-1/e (≈ 0.63)

Richard Thiessen
  • 1,741
  • 9
  • 13