hashcat Forum

While not hash based, would like to see truecrypt recovery. Dont make me bring up WPA as an arguement.

I support this, would definitely wanna see truecrypt encrypted container suppport added.

The only problem may be the "extraction" of vital info from the container, since, afaik, we dont need all the container to start cracking.
So a program like aircrack-ng to convert *.cap -> *.hccap should do it?

Oh, and if it'll be implemented, there has to be some way to control the encryption scheme and key derivation algo, perhaps using flags, or predefined hashcracking modes ?
Like -m 1333a, -m 1333b etc.
But we would need 48 modes then (3 hashing algos, 8 encryption schemes, hidden/standard containers).

definitely supporting this..
+1 vote

I don't think specifying the encryption scheme makes any sense except in some rare cases where you really know what was used. Trying all the encryption schemes is quite feasible as that happens much faster as compared to the key strengthening part. Worst part though is that you have to try all the three key strengthening algos - PBKDF2 with sha512, whirpool and ripemd160. Since likely most of the volumes use the default sha512 one, I guess the sha512 support itself would suffice at least initially.

Rolf, we're need only 512 bytes from TrueCrypt volume to start attack. For standard volumes that's 512 bytes from very beginning, so no problem at all to extract everything needed.

gat3way_, when using cascading encryption schemes we're need more output from PBKDF2 function (64 bytes per encryption algorithms, i. e. two 256-bits keys), thus making whole process slower. So limiting encryption algorithms can boost overall performance a lot if you're absolutely sure which algorithm was used.

Effectively, sha512/aes will be about 3x times faster than sha512/aes+twofish+serpent. PBKDF2/RIPEMD/2K iterations should be somewhere near PBKDF2/SHA512/1K speed while whirlpool looks like most GPU unfriendly algorithm here. Unless bitsliced version will be applicable.

IvanG, I failed to take that into consideration

I also just realized TC uses XTS mode....which is bad, keys twice longer, thus effective pbkdf2 iterations likely more than I expected

Good, good!

So, if only encrypted containers are attacked (not the hidden ones), only first half of a kilobyte is needed.
That's a bit more than hccap (which is 392 bytes), but still it's better.

Why is whirlpool GPU unfriendly ?
Does it use 64 bit ints or something ?

Oh, and IIRC, XTS is the ONLY mode which is not deprecated, so other modes should not be considered anymore (unless new, beter ones are discovered).

Whirlpool is a completely different construct as compared to most hash types we're well familiar with (like MD4, MD5, SHA1/SHA2). It is not a Merkle-Damgard construction, instead it is based on a block cipher. And the block cipher is the problem because it has s-boxes. Situation somehow resembles the DES one.

Any news about the support (or not) of Truecrypt in oclhashcat ?

Currently I only know https://code.google.com/p/truecrack/ which is only CUDA-based (and I have an ATI).
Does anybody know a soft for ATI-based cards ?

Thanks.

hashkill does it (as far as the current git tree is concerned). It's not quite useful though - unless you know something about the password and/or the algos used. Whirlpool turned out to be a disaster on GPUs and twofish on the host side may also cap the cracking speed in certain scenarios. If you don't know what algorithms were used, you need to try all of them (3 hash algos, 3 ciphers and cascaded modes).

Here are some tables with speeds on 7970:
https://www.gat3way.eu/fde

So in most cases speed will be very low, about 2K c/s on 7970. That's of course if you try all algo combinations. You don't know what was used, because there is no plaintext header which contains such information. You may of course try the default settings where speed is much better (134K c/s) but that won't guarantee you anything unless you are sure about the default settings being used. You should take into consideration the possibility of a keyfile used and if you don't have the keyfile, cracking is impossible.

I think recovering volumes using keys from memory dumps (whenever possible) is much much much better option.