5

I have read that TrueCrypt uses ~2k SHA-1 hashes on the password.

The iteration count is part of the TrueCrypt specification and is 2000 for SHA1, 2000 for RIPEMD-160 and 1000 for Whirlpool (because Whirlpool is more advanced and computationally heavy than the two others).

I recall from prior testing that my computer could do well over ~400k per second. For brute force, that comes out to 5ms per password. (The problem is probably much worse because SHA1 was just a part of the Java program I was working on.)

So for an upcoming installation of TrueCrypt I will be doing, can I lengthen the hash function? If so, I could increase the brute force cost by 50 times while only adding a quarter second to the end user wait.

If you would point me in the right direction, that would be great!

700 Software
  • 13,997
  • 3
  • 55
  • 82
  • Those statements can also be found at http://www.truecrypt.org/docs/?s=header-key-derivation – Dan D. Apr 27 '12 at 07:53

1 Answers1

5

First of all, TrueCrypt is open-source, so you could get the source and do whatever you want, provided you know how to program. But the TrueCrypt containers (or partitions, etc) would be incompatible with a non-modified TrueCrypt program.

Moving on, the "iteration count" can't be adjusted without programing. It's not a parameter that you can set anywhere in TrueCrypt. So you can't change it in an upcoming installation of TrueCrypt. And those documents you mention are outdated, 'cause the TrueCrypt docs says:

1000 iterations (or 2000 iterations when HMAC-RIPEMD-160 is used as the underlying hash function) of the key derivation function have to be performed to derive a header key, which increases the time necessary to perform an exhaustive search for passwords (i.e., brute force attack) [7].

So, it's 1000 to SHA-512 or Whirlpool, and 2000 to RIPEMD-160. It doesn't use SHA-1 anymore.

One more point is that the iteration count might seem to be low, but there's a 512-bit salt with the password. (source: truecrypt pages). That's a very big salt, which prevents rainbow tables (since any pre-computed table would have to begin with 512-bits (64-bytes) passwords).

Of course, salts don't prevent brute-force, since it's not a hidden value. That leaves you with just your password and, perhaps, with a key-file.

--- Edit: the reality about brute-force.

Wikipedia has something about the physical limits on a brute-force attack. If you choose a password that has 128 bits of entropy (that is much more than 16 bytes, since printable characters + numbers + symbols don't use the 256 possible bytes values), problably it won't be breakable before the 4th World War.

XKCD joke is also mandatory about this subject.

woliveirajr
  • 4,492
  • 2
  • 18
  • 26
  • Too bad, 1000 SHA-512 I think still comes out to under 5ms. (source, extrapolation) – 700 Software Apr 27 '12 at 16:50
  • @GeorgeBailey - You think? You do understand that the likelyhood of a brute force attack being successful doesn't decrease with the number of iterations. If your password is one where a brute force attack would have success the chances of it being sucessful stay the same. – Ramhound Apr 27 '12 at 17:40
  • @GeorgeBailey take a look at some sites like this or this one, you'll see that long enough passwords are resistant for a very long period. When you know that, creating a good password is better than a poor password with a strong hashing method. – woliveirajr Apr 27 '12 at 18:09
  • @Ramhound I think that George is worried that SHA-512 can be computed very fast (true), but strong passwords add more security than strong hash algorithms with weak passwords... – woliveirajr Apr 27 '12 at 18:11
  • @woliveirajr - I have two problems with his statement. The first is he says that "he thinks it comes out to under 5ms" so he isn't even sure and second "5ms" is a LONG TIME for a computer. There are billions of combinations, if it was a simple process, TrueCrypt would increase the iteration. In other words he is being a worry wart for no reason. – Ramhound Apr 27 '12 at 18:28
  • 1
    @Ramhound, You do understand...doesn't decrease I understand it does not decrease by much, but it does mean you can go with 6 bits less entropy than otherwise. Not much, but seems like a good idea given the cost/benefit ratio. (cost<250ms, benefit>50x cost to hacker) – 700 Software Apr 27 '12 at 18:52
  • @Ramhound, isn't even sure, Maybe I should have stated it, but I was hoping the security-competent folks on Security.SE would tell me if 5ms/1000 is significantly off base. I am not sure unless I take more time to review, or I hear confirmation from another professional. – 700 Software Apr 27 '12 at 20:46
  • @GeorgeBailey : Hi, don't want to turn this into conversation, I'll edit my answer to add some more information. – woliveirajr Apr 30 '12 at 16:12
  • 1
    128 bits? Somewhat pointless. For one thing, I won't be entering that many characters on every boot. But I do like the comic! :) – 700 Software Apr 30 '12 at 19:28