Packetizer Forums

Hi, if I have an AES encrypted file created by AES Crypt, which has lost, let's say, the first 1MB of data (so the whole header info plus more), is the file now completely unrecoverable? even if I know the password? Or there is a way to process what's left? thank you

There would be no way to recover the data if you lost the first part of the file.

One challenge is that AES Crypt uses CBC. CBC provides for better security and reduces risk of a hacker being able to recognize patterns in encrypted blocks. This makes it virtually impossible to hack part of the file.

Further, AES Crypt uses an encryption key that is stored up in the header of the file. So, if you know the password, all you are really doing is decrypting the "session key" that is actually used to encrypt the bulk of the file.

Lastly, the password is not the key used to encrypt the file or the "session key". The password is used as input in generating the encryption key. Obviously, there's no secret in that algorithm, since the source code is open for the world to see. However, there is important information in the header that is necessary to derive that key.

Thus, by losing the header of the AES Crypt file, the rest of the file is rendered useless.

Thank you, that is what I expected! Actually my plan is the following:

a) Encrypt a file twice, using encryption program A and then using AES crypt, with two different long password etc.
b) Split the encrypted file into two parts: one part is the "header" (about 2 MB) and the rest is the "body".
c) Store header and body separately (e.g. to two different online services for instance)

Only by having access to both files the encrypted file can be reconstituted and decrypted.
This would add an extra layer of security and even if an attacker gets hold of the "body", it is not even possible to try cracking the password without the header. Is that correct? What do you think? thanks

Wow, that's some serious protective measures.

Encrypting twice, especially if you use two different encryption algorithms (e.g., AES and Threefish) would certainly help make it way more difficult to crack, in theory. One would have to find an exploit in both algorithms.

If you want to split the AES Crypt file apart, the best place to do it is right before the actual encrypted message. See this page for the AES Crypt file format: http://www.aescrypt.com/aes_file_format.html.

If you split the file right where it says "nn Octets - Encrypted message (2^64 octets max)", then you basically have encrypted key data in the header and then the encrypted data in the body. The header is really small... just a few hundred octets. The size can even be reduced if you get rid of the plaintext "extensions" in the header.

Splitting it there would mean that the symmetric key and initialization vector are kept separate from the actual encrypted data. On the surface, that sounds more secure, but I'd venture to guess that any attack on AES is going to require brute-force and it might not matter that much. I'm not aware of any known exploits on AES, but at least separating it like you propose will definitely not make it easier to crack!

Let's say I did run a brute-force attack on an AES-encrypted file. Let's say I tried every possible key randomly and/or I have a vast array of parallel processors. The weak link with any encrypted file is that the first ciphertext block might reveal information. For example, the first three octets of the AES Crypt file are the letters 'AES'. If I knew that in advance, then I can more rapidly detect that I had successfully decrypted the file. If you use another program to encrypt, it might also produce an easily identifiable header. OpenSSL does, for example. So, what you might want to do is:

Encrypt with Tool 1, splitting the header and body creating header_1 and body_1.

Then encrypt body_1 using Tool 2, again splitting the header and body as header_2 and body_2. Discard body_1 and keep three files: header_1, header_2, body_2.

If somebody tried to attack body_2, even with a valid key the result would look like random junk. It would make it extremely difficult to detect that the right key was chosen.

To recover the file, you decrypt header_2 || body_2, which would produce body_1. You then decrypt header_1 || body_1.

That's certainly taking things to the extreme, but on the surface it looks like it would be extremely hard to crack. I feel pretty confident that cracking an AES file all by itself is going to be a challenge, but the above approach definitely would present challenges.

My guess, though, is any successful attack on AES or this combination would require some hard work. I doubt anyone has the resources to try every possible key, but if there are exploits found in either algorithm used, then splitting it might not help. It does "feel" stronger, though, I'll admit. What I do not know is whether a little math might reveal something that is not so obvious to my gut

Thank you! Very useful feedback!

Does the AES header part contain a hash of the password used to encrypt the file? Could an attacker try all possible password until it finds one that produces the right hash? (yes it would take several years today to do that, but still, who knows about tomorrow)... If one only has the encrypted body of the file but no password hash, he/she only needs to decrypt the file and verify that the content is decrypted correctly, that would take a lot longer?

Also, if I do not have let's say the first 2MB of the encrypted body and also have no header, can I try any password cracking attack at all or the lack of the first 2MB of the encrypted body makes the rest unusable?

thanks!

No, a hash of the password is not stored in the file. AES Crypt does compute a hash, though, and that is used as the encryption key. I'll explain...

A 16-octet initialization vector (IV) is generated and used as part of the CBC process. This IV is first inputted into an SHA-256 hash function. Then the user-provided password is added to the SHA-256 hash function 8192 times (overkill, likely, but... that's what is done). The hash computation is the 256-bit key used with the AES encryption algorithm. That's definitely not stored in the file.

To decrypt an encrypted file (that's not split into two pieces), one would have to try any of the 2^256 different possibilities that might be created by the SHA-256 hash function.

If you split the file into two pieces, it becomes a bit more complex to break. You would still have to determine the 256-bit encryption key. But, you also need the 128-bit initialization vector. Without that, when you decrypt the first 16-octet block, the block would look like random octets. Those octets would need to be XORed with the IV to get the plaintext. That basically means one would have to try 2^384 different values (the AES key and the IV). At least that would be the case with a brute-force attack.

If you don't have the header and the first 2MB of the file, the difficulty of a brute-force attack is the same as just not having the header. One would need to determine the key (256 bits) and the 128-bit random string of bits that would be used to XOR the first 16-octet block. Thus, again, one needs to consider 2^384 possible combinations with a brute-force attack.

Of course using cryptanalysis, it might be possible to eliminate some key and IV combinations to crack the encrypted file faster. I'm not aware of any such weaknesses, though. A brute-force attack on a 256-bit key would take the fasted commercially available password cracker 1.049×10^58 years to crack. That's a long time. Even if exploits made it possible to eliminate half of the possible combinations, trying 2^128 combinations would take the fastest password cracking hardware 3.083×10^19 years to crack.

One question we all have is "what exploits does the governments of the world have?" Nobody will tell us if there is one, but at least we can take some comfort in the fact that experts in cryptanalysis do try to find weaknesses and would publish any such exploits.

While you're trying to find a way to make this even more secure, here's another idea:

• Split the header from the encrypted body.
• Compute an SHA-256 hash of the header.
• XOR the encrypted body with the that hash. (Basically, read 256 bits and XOR those with the 256-bits produced by SHA-256 from the beginning of the file to the end.)

Now if somebody got the encrypted part of the file, the person would need to figure out the 256-bits of data used to XOR with the encrypted file part to re-generate the cyphertext even before one can try to crack the encryption. The only weakness with that is that 33 octets from the end of the file is a "modulo" octet that is always in the range of 0..15. So, this knowledge could be used to more quickly determine the hash used in the XOR operation. To prevent that exploit, you could move the last 33 octets of the encrypted part and put that in the header just to keep it private. Or, you could do this:

• Split the header from the encrypted body.
• Compute an SHA-256 hash of the header.
• Compute an SHA-1 hash of the header.
• XOR the encrypted body with the that SHA-256 hash.
• XOR the encrypted body with the that SHA-1 hash.

That's security through obfuscation, but it certainly would be an obfuscated mess to try to decrypt. Decrypting would require the header, re-computing those hashes, performing the XOR operations in reverse, then merging the header and encrypted body, then decrypting.

And, wow, if you will then have another layer of encryption under all that... I'd love to meet the person who might possibly be able to exploit your encrypted files.