0
$\begingroup$

I decrypted a file which was encrypted with OpenSSL and AES-128 with the wrong password. Before I noticed it was the wrong password I removed the original file. Is there a possibility to reproduce the original encrypted file? I know the "wrong" password.

Thanks in advance.

EDIT

The only file I have is the wrong decrypted file. I tried to re-encrypt that file with the used password - the password I decrypted the original file - but that doesn't work. Is there another way to get the original encrypted file?

$\endgroup$
  • $\begingroup$ Um, your question is not clear. You say you know the "wrong" password, so just decrypt the files. If you don't know the used password anymore and there's no way to get it from OpenSSL, then your files are lost. $\endgroup$ – Nova Mar 11 '15 at 23:04
  • $\begingroup$ I decrypted the file with a wrong password. Now I just have that wrong decrypted file. I tried to re-encrypt that file with the wrong password to get the original encrypted file, but that didn't word. Is there another way to get the original encrypted data? $\endgroup$ – Paul Warkentin Mar 11 '15 at 23:07
  • $\begingroup$ Can you tell us the exact openssl command you used? In particular, which cipher mode did you use, and did you use a salt? $\endgroup$ – Ilmari Karonen Mar 11 '15 at 23:45
  • $\begingroup$ So you did encrypt some special files. Then you tried to decrypt them, but with a wrong password. The original plaintext and the "correct" encrypted file are gone. Is that correct? $\endgroup$ – Nova Mar 11 '15 at 23:47
  • 2
    $\begingroup$ If you only "removed" the good file but didn't "wipe" or "securely delete" it, depending on your OS and filesystem and what else you have done on that filesystem since it may be possible to "undelete" (recover) it, or at least part of it; if you can get the first 16 bytes (which contain the salt, as explained by @Stephen) that's enough to (mostly?) recover. That's not a crypto.SE question; superuser.com might be suitable. $\endgroup$ – dave_thompson_085 Mar 12 '15 at 8:24
3
$\begingroup$

Based on your description, you will not be able to recover the original encrypted file.

Since you specify that you used a password and do not indicate the use of an IV, my assumption is that you did, in fact, use a passphrase rather than a secret key. When you encrypt a file with a passphrase, OpenSSL assumes that it is a low-entropy string unsuitable for use as a cryptographic key (which is assumed, for AES, to be a random 128-bit or 256-bit string). To turn the passphrase into a suitable key, it performs key stretching: a random salt is generated, and it is hashed together with the key a large number of times in order to increase the amount of effort needed for an attacker to guess the original input. The result is then used as the key.

Unfortunately, it is this random salt which prevents you from reencrypting back to the same file. If you had used a fixed key and IV (initialization vector), it would in general be possible for you to simply reencrypt the data with the two inputs you had mistakenly used, and recover the original encrypted file. However, since a random salt is used in the process to produce a key from a passphrase, and that random salt is stored in the file you decrypted, there will be no way to guess what that value was and therefore ensure you reencrypt with the same key and IV inputs.

$\endgroup$
  • 1
    $\begingroup$ Nitpick: openssl enc does do PBE in most cases including this one, but it does NOT hash "a large number of times" as PBE should; instead it does a variant of PBKDF1 (old, but tolerable) with iteration count 1 YES I SAID ONE. Unlike other openssl defaults that were reasonable when chosen a decade or two ago but now superseded or deprecated, n=1 was bad from the start. But as you say the problem here is the salt and that was done right. $\endgroup$ – dave_thompson_085 Mar 12 '15 at 8:35
  • $\begingroup$ One could be a large number. :) $\endgroup$ – Stephen Touset Mar 12 '15 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.