OTFBrutus improvement for faster truecrypt brute force

Hello all,

first of all thanks tateu for your program OTFBrutus!. Very nice work, well done! I hope you still continue development?

Mainly i want to discuss here how to improve the speed of OTFBrutus. I myself worked on another brute force tool recently and some of the ideas apply here too.

Lets start with one thing concerning the xts mode (please correct me if i am wrong):
When a key is to be tested, the full tc header (512 bytes) is decrypted. If then the magic string "TRUE" (which is located at byte 64..67 in the header) is not found, the further processing (crc32 calculation etc.) is skipped for this key. Now, shouldn't it be possible to only decrypt the 1st block (for AES its size is 16 bytes) then check for magic and do the remaining decryption only if magic is found? As the magic is the first data in the encrypted section, i assume it is decrypted first (the xts loop in XTS.c looks like its counting from low to high block numbers). If this works, the decryption part would be 512/16 = 32 times faster.
For the moment i think decrypting the remaining data can just be skipped because the probability for the magic to be correct "by accident" is very low (2^32) and collisions with the current speed only happen within years.

What do you think?

 

Sorry to reply so late...just saw this now...

The decryption is such an insignificant part of the bruteforce process, it's not worth the effort. The only thing that makes any difference is the hash function and the number of rounds that must be performed.

Just run OTFBrutusGUI twice to see what I am talking about. Run it once with all encryption algorithms turned on. Then run it a second time with only one encryption algorithm turned on. They should both run at almost the same speed. On my old Pentium 4 machine, with all encryption algorithms on and all other settings left at their defaults, it tries about 11.5 passwords per second. With only AES turned on, it tries about 11.7 passwords per second.

So, with 13 less algorithms (some of them cascades) the speedup on my machine is only 0.2 passwords per second. In contast, if I remove RipeMD and Whirlpool, leaving only SHA512, it can try 50.5 passwords per second.

 

ok i see, the header key derivation with its 1000 or even 2000 iterations takes most of the time. This makes sense.

Then i think the only way to get a speed gain is to use bit-slicing for the HMAC functions. Have you thought about that?
If this works, it should give a considerable speed gain.

For those who do not know what the bit slice technique is about, this may be a good start to read http://plaintext.crypto.lo.gy/article/378/untwisted-bit-sliced-tea-time
It was first implemented for DES and there are some other implementations around. Unfortunately i cannot find any for the hmac functions used in truecrypt. To implement them is much work for sure...

 

Hello Tateu,

also from my side - thank you very much for your work on OTFBrutus - it's awesome
I have a windows 2k8 server running here which is not willing to work with OTFB (still version 0.1.0.8.), therefore I installed an w7x64 vm in vmware, using 2 processors each 4 cores. First I was happy for this "workaround skalable way (by choosing different offset by hand)", but after unpredictable time of wb-attack, OTFB dies for a reason I don't get.
I postet as reply here because maybe some other have a set of machines and are interested in virtualization. This approach may sound crazy because loss of speed, but I still get 311 Passwords a second on that four year old bitch

Thank you for any hint