2
$\begingroup$

When encrypting a file say with Winrar you have to enter a password. I am under the impression that this password is not stored anywhere but instead the password together with some other attributes and an IV create a hash of some sort.Is that hash stored or attached to the encrypted file ?

Then when trying to decrypt the file by means of an user fed password, is the hashing process repeated to verify that the stored hash matches the generated hash for the decryption process to begin?

I mean,there has to be something stored in the encrypted file;maybe not the password but a hash...

$\endgroup$
4
$\begingroup$

The hash that is generated from the password is actually the derived key, and is definitely not stored inside the file (there are exceptions). It is not compared to any data, it is used for encryption and decryption.

There does not have to be something in addition to the ciphertext for the software to determine the password is correct. In many cases, decryption follows authentication, but it is not necessary to determine anything. The file will be decrypted, and decompression will most likely fail in the case of an incorrect password, if it does decompress the data will be junk.

That is of course not optimal from a usability standpoint. It is best for the user if they know the password is incorrect. That has to be done in a manner that does not give a huge advantage to an attacker. There are a several easy methods to accomplish this, here are a few of them.

1: A checksum or hash of the compressed data is added prior to encryption. Upon decryption, the data is then hashed, and compared against the decrypted hash. If it matches, it decrypted properly. This can also be done at a block level, such as every 16KB, so the correctness of the decryption can be determined earlier.

2: A "magic string" is the more common method in older encrypted archive formats. The compressed data includes some known prefix or suffix such as 0x52 0x61 0x72 0x21 0x1A 0x07 0x00 and 0xC4 0x3D 0x7B 0x00 0x40 0x07 0x00 in the case of WinRAR, and since the position of these strings should be in an expected location, decryption of those locations will reveal the string if the password is correct and the data is unmodified. This is not necessarily the way WINRAR handles it, but is just an example.

3: A secondary data encryption key is encrypted with a key derived from the password. This allows the password to be changed without reencryption of the data, and will also allow authentication of the data key component to know the password is correct, without having to look at the encrypted data of the archive.

$\endgroup$
  • $\begingroup$ >The file will be decrypted, and decompression will most likely fail in the >case of an incorrect password. That is the thing;how does it judge that the password is wrong in cases that none of the 3 side points you present are in effect? $\endgroup$ – microwth Sep 14 '16 at 20:45
  • $\begingroup$ Quote from above: "The file will be decrypted, and decompression will most likely fail in the case of an incorrect password, if it does decompress the data will be junk." $\endgroup$ – mat Sep 15 '16 at 10:05
  • $\begingroup$ @mat this explains what happens if the password is incorrect, it doesn't explain how is it discovered that it is in fact incorrect $\endgroup$ – microwth Sep 15 '16 at 14:20
  • $\begingroup$ @microwth, many algorithms have 0 checks to see if the password or key is correct, they simply process the data with an incorrect key, generating useless data. In the case of an archive format, that useless data will no longer match the format expected, and fail to decompress $\endgroup$ – Richie Frame Sep 15 '16 at 20:52

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.