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!

Improve this question
1

1 Answer 1

Reset to default
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.

Improve this answer
9
  • Too bad, 1000 SHA-512 I think still comes out to under 5ms. (source, extrapolation)
    – 700 Software
    Apr 27, 2012 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, 2012 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, 2012 at 18:09
  • 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, 2012 at 18:52
  • 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, 2012 at 19:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .