of one hashing algorithm with another hashing algorithm? That is not clear at
the moment.
After the MD5 function returns (and assuming it returns a nonzero value),
the function proceeds to call an interesting API called CryptDeriveKey.
According to Microsoft’s documentation, CryptDeriveKey“generates cryp-
tographic session keys derived from a base data value.” The base data value is
taken for a hash object, which, in this case, is a 160-bit SHA hash calculated
from the plaintext password. As a part of the generation of the key object, the
caller must also specify which encryption algorithm will be used (this is spec-
ified in the second parameter passed to CryptDeriveKey). As you can see in
Listing 6.5, Cryptex is passing 0x6603. We return to WinCrypt.Hand dis-
cover that 0x6603 stands for CALG_3DES. This makes sense and proves that
Cryptex works as advertised: It encrypts data using the 3DES algorithm.
When we think about it a little bit, it becomes clear why Cryptex calculated
that extra MD5 hash. Essentially, Cryptex is using the generated SHA hash as
a key for encrypting and decrypting the data (3DES is a symmetric algorithm,
which means that encryption and decryption are both performed using the
same key). Additionally, Cryptex needs some kind of an easy way to detect
whether the supplied password was correct or incorrect. For this, Cryptex cal-
culates an additional hash (using the MD5 algorithm) from the SHA hash and
stores the result in the file header. When an archive is opened, the supplied
password is hashed twice (once using SHA and once using MD5), and the
MD5 result is compared against the one stored in the archive header. If they
match, the password is correct.
You may wonder why Cryptex isn’t just storing the SHA result directly into
the file header. Why go through the extra effort of calculating an additional
hash value? The reason is that the SHA hash is directly used as the encryption
key; storing it in the file header would make it incredibly easy to decrypt
Cryptex archives. This might be a bit confusing considering that it is impossi-
ble to extract the original plaintext password from the SHA hash value, but it
is just not needed. The hash value is all that would be needed in order to
decrypt the data. Instead, Cryptex calculates an additional hash from the SHA
value and stores that as the unique password identification. Figure 6.1 demon-
strates this sequence.
Finally, if you’re wondering why Cryptex isn’t calculating the MD5
password-verification hash directly from the plaintext password but from the
SHA hash value, it’s probably because of the (admittedly remote) possibility
that someone would be able to covert the MD5 hash value to an equivalent
SHA hash value and effectively obtain the decryption key. This is virtually
guaranteed to be mathematically impossible, but why risk it? It is certainly
going to be impossible to obtain the original data (which is the SHA-generated
decryption key) from the MD5 hash value stored in the header. Being overly
paranoid is the advisable frame of mind when developing security-related
technologies.
Deciphering File Formats 217