16

I had encrypted 2 MySQL databases with AES_ENCRYPT in ECB 128 bit mode. Now I forgot my encryption key, but I have plain text (I have one database without encryption and same with encryption). How to find the encryption key so I can decrypt my other database?

I heard about known plain text attack, how to do this? Is there any tool in Kali Linux or some python script on GitHub?

4
  • 3
  • 20
    If recovering an encryption key knowing the plain text was a real possibility encryption would be worthless.
    – zaph
    Dec 17, 2018 at 17:16
  • Depends on the bit size tho.
    – Valmond
    Dec 17, 2018 at 21:47
  • 1
    When you say you “forgot”, do you mean it’s based on a passphrase that you forgot? I have a program that will try variations on an imperfectly-remembered passphrase. It can be useful if you remember the words but can’t remember the punctuation and such.
    – Tom Zych
    Dec 18, 2018 at 0:03

3 Answers 3

35

Realistically, no you cannot. AES is very resistant to known plaint text attacks like most block ciphers. It's lucky you didn't lose any information and have the original database backup because your only real option would be to try brute force the encryption, which is likely to take longer than the length of the universe (unless you can greatly narrow down possible keys by almost remembering your password?)

7
  • 1
    Then, why people say "ECB is insecure" ? Dec 17, 2018 at 6:30
  • 3
    Have a read of: crypto.stackexchange.com/questions/20941/… A crypto protocol being 'insecure' doesn't always mean it can be easily cracked, just that it is not as secure as other alternatives.
    – Aide
    Dec 17, 2018 at 6:33
  • 4
    @huishanki To elaborate: ECB's insecurity is in recovering information about the plaintext from the ciphertext (see the linked answer for examples). Since you already have the plaintext, this is of very little use to you.
    – Cyclic3
    Dec 17, 2018 at 11:05
  • 13
    I love this picture on Wikipedia of and ECB-encrypted bitmap. Dec 17, 2018 at 16:30
  • 2
    @huishanki, ECB doesn't hide large-scale patterns in the data, and the same partial plaintext always encrypts to the same partial ciphertext. Using ECB means that if you know part of the data in both plain and encrypted forms, you can find other places that have the same encrypted form, and you then know what the plaintext form of that part of the data is.
    – Mark
    Dec 18, 2018 at 4:16
11

What you are asking for is a known-plain-text attack (KPA). The weakness you describe in ECB is where two encrypted blocks with the same plaintext are encrypted with the same ciphertext.

This just means you know that two encrypted blocks in the ciphertext look the same, it doesn't mean that you can recover the plain text easily. The answer is: no you will not be able to recover the key.

2
  • Since it's in ECB mode, and the two DBs use the same key, isn't it possible to figure out from the first database a dictionary of the ciphertext corresponding to any given plaintext in the first database, and use that to look up a partial plaintext for the second?
    – Ben
    Dec 17, 2018 at 15:39
  • Thats providing all your block permutations can map back to a plaintext. Which wont be the case. Dec 17, 2018 at 15:42
1

This is called a known plaintext attack against a cipher and is a major design consideration. What you want to do is considered to not be possible barring any major revelation into a weakness in AES. There is another Q/A here that might help you understand further:

https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks

Ciphers only operate on a fixed length of bits, so chaining modes are used to encrypt arbitrary lengths of data. ECB is the most simple one, it just encrypts one block at a time. The main weakness is that identical blocks produce the same encrypted output which is a major leak of information. It also creates opportunities for replay attacks where an attacker can just re-send encrypted blocks that they think they know the contents of. Unfortunately this does not get you anywhere closer to key recovery with a known plain text.

One viable attack for you might be if you used a password to generate the key, and you remember for example that it is exactly 12 characters long and has three digits. This majorly limits the password space and might allow a brute force analysis to work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .