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:

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:

This feature will be available in the next 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

- AES

- Serpent

- Twofish

- AES-Twofish

- AES-Twofish-Serpent

- Serpent-AES

- Serpent-Twofish-AES

- Twofish-Serpent

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:

- AES

- Serpent

- Twofish

- AES-Twofish

- Serpent-AES

- Twofish-Serpent

- AES-Twofish-Serpent

- Serpent-Twofish-AES

This feature will be available in the next version :-)