Yeah, that subject really sounds like some bad advertisement, but it actually describes my discovery pretty good, I promise! I don't know if this really is new, however for me it is and it will definitely make it's way into the next oclHashcat version.
The current release version of oclHashcat (v1.37) is already able to crack TrueCrypt volumes, though it only is able to crack AES encrypted volumes. However, I'm in the middle of implementing the other ciphers too, including the cascaded ciphers.
TrueCrypt lets you choose between three different hashing algorithms and three different ciphers, additionally you can combine the ciphers (and cascade them) to a total of eight different ciphers. Cascading just means that your data is first encrypted with, for example, AES and the output of which is again used as input for another round of encryption, for example with Twofish. Here's a full list:
Hashes:
- RipeMD160
- SHA512
- Whirlpool
Ciphers:
Additional cascaded ciphers:
- AES-Twofish
- AES-Twofish-Serpent
- Serpent-AES
- Serpent-Twofish-AES
- Twofish-Serpent
The first problem you encounter when attacking TrueCrypt is the lack of headers in the TrueCrypt volume. The header would contain metadata, which would tell you about the hashing algorithm and the cipher being used and also if it is actually a TrueCrypt volume. For comparison LUKS does include a header with identifiable informations. My guess is that some just believe this to be more secure. An attacker can not know that this file is a TrueCrypt encrypted volume by only seeing the pure data without context, it just looks like random garbage. But in most cases the attacker knows that some files are really TrueCrypt encrypted volumes due to the enabled "history" feature (which for convenience remembers the filename used) or simply because of an obvious filename.
The next problem for the attacker is that he does not know which hashing algorithm and which cipher was used to create the volume. Funny side note, TrueCrypt does not know either. As a matter of fact both have to simply try all possible combinations by decrypting the first block of data. This first block (after decryption) contains a known and fixed marker and some other checksums. If an attacker (or the TrueCrypt software itself) can confirm that marker after decrypting the first block, given the correct key, the current hashing algorithm and cipher will be selected.
Though, because only the user knows the password, this only works for the real user. The attacker has both problems at once, he does not know the password and he does not know the hashing algorithm or the cipher. We can come to the conclusion that an attacker has to try the same password against a total of 24 different combinations. This means oclHashcat will support 24 different modes (actually more because of hidden-volume and boot support) to crack TrueCrypt volumes.
The way TrueCrypt works is that it will know by the selection of the cipher or cascaded cipher which output keysize to compute using the KDF function. For example "AES-Twofish-Serpent", the creation involved three different ciphers, each of size 512 bit. It takes the password from the user and sets the output keysize for the KDF function to 1536, the reason being: 3 * 512 = 1536. And here comes the problem:
Because of how PBKDF2 is designed, the first 512 bits are always the same regardless of the selected output keysize. This is also true for the next 512 bits and the last 512 bits. In other words, the leading bits of the output key do not change whatever TrueCrypt selects as cipher or cascaded cipher. It's important to note that this behavior with PBKDF2 is not some sort of bug, this is simply of how it is supposed to work.
In the case of TrueCrypt the KDF is the slowest part. This is good as the KDF should be slow to avoid fast cracking rates. However, as described previously, we can reuse the first 512 bits for the ciphers:
The second 512 bits for the ciphers:
- AES-Twofish
- Serpent-AES
- Twofish-Serpent
The final 512 bit for the ciphers:
- AES-Twofish-Serpent
- Serpent-Twofish-AES
To make use of this, oclHashcat will come with a 9th cipher mode that will always calculate 1536 bits and reuse them as it covers each combination of cipher or cascaded ciphers. For example when selecting the RipeMD160 hash, oclHashcat will calculate 1536 bits instead of 512. Therefore the amount of work items increase from 4 to 10 (512/160 and 1536/160, respectively), but on the other hand we can test all the ciphers at once! Otherwise we would need to calculate the key for all 8 ciphers which is a total of 53 work items. Finally this means we reduced the number of workitems from 53 to 10, which is a effective cracking speedup of 530%.
This feature will be available in the next version :-)
