RE: password protect pen drive

[David Denney <d.denney () networkharbor com>]

I believe that most of the answers you seek are at http://www.truecrypt.org/docs/ -> Technical Details.
Especially the sections "Header Key Derivation, Salt, and Iteration Count", and "Encryption Scheme".

The short answer is that the first 512 bytes of every TrueCrypt volume is used as a salt value.

TrueCrypt's documentation is quite good, and an interesting read.

denney


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of krymson () gmail com
Sent: Monday, July 21, 2008 3:56 AM
To: security-basics () securityfocus com
Subject: Re: password protect pen drive

Yes, hashes can be brute-forced, but can they all have a rainbow table associated with them? Not realistically.

I was hoping to shake out someone who could comment that TrueCrypt passwords are salted as part of the process, since I 
don't know. :)



<- snip ->
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

krymson (at) gmail (dot) com [email concealed] wrote:
> First, I'm curious, can TrueCrypt passwords actually have rainbow tables? I don't think so, depending which password 
> encryption/hash you use with TrueCrypt. I'm pretty sure they're exempt from realistic rainbow table use.

When you generate a password, if the product is making a hash of what
you entered, then it can be brute forced.

You are generating a hash of a character, matching that hash to the
existing hash. No match, move on.

> Second, how do you come by the 1.68 hours to crack the password? I have no doubt one can bruteforce the TrueCrypt 
> password, but you will need to devise your own script and also a positive check in order to do it, no? I wouldn't be 
> surprised if something can run through TrueCrypt attempts quickly (depending on how fast it tells you 'fail'), so I'm 
> just curious where that number came from.

I have a magickal took that will give a guestimate as to the amount of
time. In this particular case, we were given an exact password. So I
told my tool that this is the criteria, so how long will it take.

Or you can do it the "real" way and figure out the math.

It is a computation problem, dealing with X number of possibilities
being processes at X speed, you will arrive at an answer in X amount of
time.

> Third, I don't know any system that can't be brute-forced when the password is simple or easy. It's just a matter of 
> how costly it is for the attacker to accomplish. You would need lockouts or timeouts to make this too costly for an 
> attacker to wait for. Or use a large password that would take a long time to process. For something as "stripped" as 
> disk encryption, you'll want to use a long password as opposed to expecting a vendor to build more intelligence into 
> the process.

ALL systems can be brute forced. It is simply a matter of time.

I am aware of Rainbow Tables that are in excess of 54 character hashes
in length. Therefore, if that was what I was told, I would assume much
larger.

What you are banking on is whether or not you can devise a password that
is strong enough to withstand the attack.

Are you going to have one chucklehead using his mommy and daddy's 'puter
trying to hack away at you? Or are you going to have someone with some
skills and a gigantic botnet of computers that are just waiting for
something to "work on".

Yes, lockouts and timeouts are very important. But those don't apply to
everything. They are only meant to slow down the attack. And if
someone REALLY wants it, a timeout isn't going to be enough to stop them.

So leave those 8 character passwords at home. They are not safe any longer.

You really shouldn't be using anything under 16.