3

How hard is it for a given ciphertext generated by a given (symmetric or asymmetric) encryption algorithm working on a plaintext/key pair, to find a different plaintext/key pair that yields the same cyphertext?

And how hard is it two find two plaintext/key pairs lead to the same cyphertext?

What led to this question, is another question that might turn out to have nothing to do with the above questions:

If you have a ciphertext and a key and want to decrypt it using some decryption routine, the routine usually tells you, if the key was correct. But how does it know it? Does it look for some pattern in the resulted plaintext, that indicates, that the decryption was successful? Does there exists another key results in some different plaintext, that contains the pattern and is also reported "valid" by the routine?

Follow-up question inspired by answers and comments:

If the allowed plaintext/key pairs where restricted in the on of the following (or both) way(s):

1) The plaintext starts with the KCV (Key check value) of the key.

2) The plaintext starts with a hash value of some plaintext/key combination

Would this make the collision finding infeasible? Is it even clear, that such a plaintext/key exists=

Johannes Gerer
  • 25,508
  • 5
  • 29
  • 35
  • You've got some good guys answering your questions here, but I would normally bet on [crypto](http://crypto.stackexchange.com/) regarding these sort of questions. – Maarten Bodewes Feb 26 '12 at 19:49
  • Thanks, I did not about that site! – Johannes Gerer Feb 27 '12 at 17:25
  • Don't use a KCV or a hash of a plain text/key combination. There is a wealth of research on the vulnerabilities of such schemes. Use an Encrypt-then-Authenticate scheme, such as first AES-CBC and then HMAC-SHA256. – Henrick Hellström Mar 06 '12 at 12:39

3 Answers3

9

The answer to your question the way you phrased it, is that there is no collision resistance what so ever.

Symmetric case Let's presume you got a plain text PT with a length that is a multiple of the block length of the underlying block cipher. You generate a random IV and encrypt the plain text using a key K, CBC mode and no padding.

Producing a plain text PT' and key K' that produces the same cipher text CT is easy. Simply select K' at random, decrypt CT using key K' and IV, and you get your colliding PT'.

This gets a bit more complicated if you also use padding, but it is still possible. If you use PKCS#5/7 padding, just keep generating keys until you find one such that the last octet of your decrypted text PT' is 0x01. This will take on average 128 attempts.

To make such collision finding infeasible, you have to use a message authentication code (MAC).

Asymmetric case Something similar applies to RSA public key encryption. If you use no padding (which obviously isn't recommended and possibly not even supported by most cryptographic libraries), and use a public key (N,E) for encrypting PT into CT, simply generate a second key pair (N',E',D') such that N' > N, then PT' = CT^D' (mod N) will encrypt into CT under (N',E').

If you are using PKCS#1 v1.5 padding for your RSA encryption, the most significant octet after the RSA private key operation has to be 0x02, which it will be with a probability of approximately one in 256. Furthermore the first 0x00 valued octet has to occur no sooner than at index 9, which will happen with a high probability (approximately 0,97). Hence, on average you will have to generate on average some 264 random RSA key pairs of the same bit size, before you hit one that for some plain text could have produced the same cipher text.

If your are using RSA-OAEP padding, the private key decryption is however guaranteed to fail unless the cipher text was generated using the the corresponding public key.

Henrick Hellström
  • 2,556
  • 16
  • 18
4

If you're encrypting some plaintext (length n), then there are 2n unique input strings, and each must result in a unique ciphertext (otherwise it wouldn't be reversible). Therefore, all possible strings of length n are valid ciphertexts. But this is true for all keys. Therefore, for any given ciphertext, there are 2k ways of obtaining it, each with a different key of length k.

Therefore, to answer your first question: very easy! Just pick an arbitrary key, and "decrypt" the ciphertext. You will get the plaintext that matches the key.

I'm not sure what you mean by "the routine usually tells you if the key was correct".

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
  • and you cannot possibly do better than a key of size n. – UmNyobe Feb 26 '12 at 18:30
  • hi Oli, just voted this answer up, but don't forget that Johannes asked the question for "a given (symmetric or asymmetric) encryption", which complicates the answer a bit. Padding may also be an issue. – Maarten Bodewes Feb 26 '12 at 19:40
  • "the routine usually tells you if the key was correct" refers to end-user encryption software that usually informs the user if a supplied key is the "right" one. – Johannes Gerer Feb 27 '12 at 17:38
0

One simple way to check the validity of a key is to add a known part to the plaintext before encryption. If the decryption doesn't reproduce that, it's not the right key.

The known part should not be a constant, since that would be an instant crib. But it could be e.g. be a hash of the plaintext; if hashing the decrypted text yields the same hash value, the key is probably correct (with the exception of hash collisions).

Roland Smith
  • 42,427
  • 3
  • 64
  • 94
  • From the wikipedia page you linked to: "Modern ciphers such as Advanced Encryption Standard are not currently susceptible to known-plaintext attacks." Actually, a well known method of generating a key ID is to encrypt a block of all zero's and possibly remove some information from it, this is called the KCV (key check value). The way you discribe the use of hash functions and the problem with hash collisions leaves something to be desired as well. – Maarten Bodewes Feb 26 '12 at 19:48
  • Nevertheless the method of adding a hash or checksum is used. E.g. in the `scrypt` utility; http://www.tarsnap.com/scrypt.html – Roland Smith Feb 26 '12 at 20:57
  • scrypt uses a hash to derive a key, that's not the same thing as hashing plain text and then encrypting it. The latter is rather useless as it still will produce a static value - you might as well encrypt all zero's. – Maarten Bodewes Feb 26 '12 at 21:01
  • It uses SHA256 to add a signature to the header to verify the password. See scryptenc_setup in lib/scryptenc/scryptenc.c – Roland Smith Feb 26 '12 at 21:19
  • @owlstead: Why does hashing the plaintext produce a static value? And why is this an issue if "Modern ciphers such as Advanced Encryption Standard are not currently susceptible to known-plaintext attacks.". And what is the KCV used for? – Johannes Gerer Feb 27 '12 at 17:34
  • @JohannesGerer: If the plain text is known, then so is the hash, so I don't really see how that's going to help. Futhermore, any secure cipher such as AES does not leak information about the key if plain text is known (although this cannot be proven). A KCV (key check value) is e.g. used within the PKCS#11 cryptoki standards to uniquely identify a key, without showing information about it. Normally it's the first X bytes (e.g. 3) of the encryption of a block of all zero's. – Maarten Bodewes Feb 28 '12 at 18:26
  • @owlstead: No, I think there is a misunderstanding. The plain-text is not known. Instead you decrypt the ciphertext using some key and want to check the integrity of the resulting plaintext, by checking, if the first n characters equal the hash value of the remaining characters. – Johannes Gerer Mar 01 '12 at 04:48