Packetizer Forums

Hi,
I have to recover some lost encrypted files from an hard disk of mine, and I'm using a freeware software to recover lost data. So I succedeed in finding the files but everytime I try to recover them the process fails. I'm sure it's due to encryption algorithm (AES 256).
So the question is: is it possible to use a software that implement the encryption key in the system (windows xp)?
If the system run such a software, I'm sure I 'll be able to recover those files, becouse is the system itself that decrypt what the recovery software is recovering. Please tell me if this enc-decryption software exist and, if yes, its name.
Thank you in advance for your help
best regards

It sounds like this is not related to AES Crypt, but perhaps Windows encryption software? Do you know what the files were encrypted with?

If they're encrypted using AES Crypt, the only way to recover the files is to have the password.

Hi
I've the same kind of problem.
I am seeking tools to help me recover some files that I must have AES-encrypted by use of a USB Pen Drive utility (CarryItEasy) that I have probably mis-used.
That utility is not offering possibility to open individual files.

I think I remember the password I used at that time, and I am wondering if and how I can use AESCrypt to attempt decrypting a file encrypted by means of another tool.
When I right-click the encrypted file Windows only offers the possibility to AES-Encrypt it - no AESDecrypt option is offered, unless the file has been encrypted by AESCrypt.

Any workaround?
Thanks for support. For me it is extremely important.

Best regards
Stefano Nicastro

I can't say whether the USB Pen Drive utility encrypts files using the same file format or not. One way to test, if you think you know the password, is to rename the file to have an extension ".aes" and then try to decrypt the file. If it is not a valid AES Crypt file, it will tell you so. If the password is wrong, it should tell you that, too.

If you know how to look at the raw bytes of the file, a quick look there would tell you. The first three bytes of an AES Crypt file are 'AES'. I'm not aware of any other tools that do that.

Paul

paulej wrote:If you know how to look at the raw bytes of the file, a quick look there would tell you. The first three bytes of an AES Crypt file are 'AES'. I'm not aware of any other tools that do that.

Paul

I was browsing the forum when I came across this. If I understand you correctly, AES Crypt prepends "AES" to the encrypted file.

Doing this has two apparent drawbacks without any apparent advantages. Firstly, this effectively proves that the file is ciphertext as opposed to random data. Secondly, it means that the ciphertext cannot be decrypted by any program other than AES Crypt without surgery on the raw file.

Am I missing something?

lotus49 wrote:Doing this has two apparent drawbacks without any apparent advantages. Firstly, this effectively proves that the file is ciphertext as opposed to random data. Secondly, it means that the ciphertext cannot be decrypted by any program other than AES Crypt without surgery on the raw file.

Prepending AES does not weaken the security of the encrypted file. A file should be secure because it uses a secure algorithm. If the file cannot withstand an attack knowing that it is an AES file, I would not want to use the algorithm. Trying to "hide" that would suggest the algorithm cannot withstand an attack.

As for using other software packages, the format we use absolutely does not prevent that. In fact, we encourage other software packages to use the same format to make it possible for various products to share a common file format. Having AES prepended or the other stuff we introduced in the .aes file does not make this more difficult or easier. In fact, one would not want to merely run the plaintext file through AES and produce a ciphertext file. This would result in every block of plaintext that shared the same sequence of bytes to be encrypted the same way. The prevent that, AES Crypt uses a technique called Chaining Block Cipher:
http://en.wikipedia.org/wiki/Block_ciph ... _operation

To use that, one must have an initialization vector (IV). That must also be stored in the file somehow. We would also like to be able to detect if the file has been corrupted or modified in some way, so we use an HMAC to provide this protection:
http://en.wikipedia.org/wiki/HMAC

All of this comes together to produce a file format we defined:
http://www.aescrypt.com/aes_file_format.html

You will find that all encryption packages must define and use some file format that is more than merely the output of a block cipher routine like AES, otherwise they are vulnerable to attack.

Paul

Thanks for the reply Paul.

I wasn't suggesting that knowing that a file is encrypted in any way increases the likelihood that the file may be decrypted. My reason for this is to do with plausible deniability a la Truecrypt and similar products.

If I have a file entitled (say) randomseeddata.bin of which the first three bytes were "AES", I could hardly claim that this file is not encrypted data. Sometimes this matters, particularly if someone attempts to force the user to reveal the key under some legislative procedures such as the Regulation of Investigatory Powers Act in UK which permits a court to imprison someone if they refuse to hand over an encryption key. To be able to do so, the prosecutor must demonstrate that the file is actually encrypted. They do not need to be able to prove anything about what the contents of the file are or may be.

On the second point, you raise a fair point about using IVs to defeat cryptanalysis, but as far as I understand it, other utilities such as the widely used ccrypt do not have a file format as such. I shall have to do a bit of digging as to how ccrypt deals with the risks of cryptanalysis.

That's an interesting use case. I had seen that with trucrypt, too. That tool even goes so far as to allow one to create hidden volumes, which I assume nobody would necessarily know was there. I suspect I could determine if there as cryptographic data, though. One technique would just be to look at the raw bits and look for recurrences. In non-encrypted data, the probability of getting one value more frequently than another is greater. With an encrypted file, I assume the probability is more or less equal. That may or may not be the case with Trucrypt, but I suspect it is.

All encrypted files I've seen so far have some kind of signature about them, though it might not be as blatant as "AES" appearing at the front. Just before the end of 2010, Wikileaks published an encrypted file that was encrypted using 256-bit AES. They did not use AES Crypt, though. I could look at the file and immediately see that it was encrypted with OpenSSL. The signature is distinct with that tool, too.

It could certainly be possible to produce a file that did not have any kind of signature. The IV is random data and the encrypted text is random data (or appears to be). Still, I'm not sure one could deny that a file is not encrypted. The only bit of data that would still concern me is the file size modulo byte near the end of the file. I could encrypt that, too, so that it is not clearly visible.

I might put this on the to-do list, perhaps introducing a new switch to hide information that is presently in plain view.