how does decryption program know when it was successful

[supernova87a]

hi all -- I have been vaguely curious about this for a little while --

when you have an encrypted file, and you go to decrypt it with whatever program, it will ask you the key, and begin decrypting if correct. But how does it know if the key is correct or not? I.e. you can decrypt a file with any password/key, and it is not like the program should know if it's right or not.

Does it look at the file contents to see if what's coming out makes sense, in some standardized header for example? But if the original file was gibberish (as a test), how could it tell?

One friend suggested that the correct password is the first thing in the file, so that the program sees that what you entered exactly matches the first thing out of it. That could work, but then isn't having a known piece of information at the very beginning of the file self-defeating of the encryption? You would be able to figure out what input key would generates the first string that is itself, right?

would be glad to know the answer from you all!

 

[Nathelion]

Some of the more retarded encryption software out there does indeed store the correct key in a manner similar to what your friend suggested. You are entirely right, it defeats the purpose of encrypting to begin with.

 

[TuxDave]

I suspect it does a form of error checking where if the key was right, it should expect some standardized data to appear in a set location (the decrypted file has to end with 64 0's or something). So it'll decrypt using the key and if it doesn't get what it's supposed to get at the end, the program will know the key was wrong and all it did was generate a pile of gibberish.

 

[Aberforth]

The encrypted data has a unique signature (like a fingerprint) called hash values, so when you enter an invalid decryption key the software tries to convert your key in to standard hash values and tries to match it with the hash value of the encrypted data.

To encrypt a data with signature you need encryption algorithm and Signature Digest

Like: Blowfish and SHA 256 Digest or NSA SkipJack and MD5, ZIP files use CRC 32.

 

[Mark R]

Before the data is encrypted, a 'check' value is calculated e.g. a CRC value, or some form of hash (e.g. SHA1 or MD5). The same check value will always be calculated for the same data, but a small change in the data will completely alter the check value. This is the same principle that certain files types (e.g. ZIP) use to make sure that they are not corrupted; when a file is zipped, the CRC is calculated and stored in the file. When the file is unzipped, the CRC of the unzipped file is calculated and compared to the value stored in the ZIP. If the 2 are different, something went wrong with the unzipping.

This same principle is used with encryption. The CRC (or better a sophisticated hash) is calculated before encryption and stored with the file. After decryption, the hash is calculated from the decrypted data. If it matches, it pretty much guarantees that the decryption was successful. If it doesn't, then something went wrong, usually meaning that the key was wrong.

E.g. In RAR files, no specific check is made on the decryption key. If you put the wrong password in, the CRC doesn't match, and you get a 'CRC doesn't match error'. You get the same error if the file is hosed.