Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I've read various articles on password strength and passwords vs pass phrases (including the one from XKCD and its thread here), but most of those articles seem to be focused on online passwords, and make claims like passwords only needing to be safe for 70 days (until you change them) and usually assume some form of limitation, like network latencies, etc.

My question is, what is a reasonable estimate for password-guesses per second for disk ecnryption systems (like Truecrypt)? The only true limitation here is the number of CPUs available to the attacker (since cracking attempts can be easily parallelized).

Even something as high as 10^12 guesses/second seems like a low estimate, when considering that at 1 guesses/clock-tick, with 1GHz-CPUs, that only means 1000 CPUs working in parallel.

How much do the key-derivation schemes built into disk encryption software (like Truecrypt's application of SHA/Whirlpool) really help here? By how much can they realistically lower the guesses/clock-tick factor?

The problem with XKCD's scheme, I'm afraid, is that in order to get some 30ish years (I guess that's a reasonable estimate for the statute of limitations, for most legal matters, in most countries) of security out of it, you'll need 7 words .. and remembering all of them in the correct order isn't really that much easier than some 16-character obscure combination

share|improve this question
    
Very similar to security.stackexchange.com/questions/12114/… –  CodesInChaos Jun 15 '12 at 13:09
    
A try is more like 100k cycles, but truecrypt's iteration count is far too low IMO. –  CodesInChaos Jun 15 '12 at 13:10
    
Thanks for your comments. They do answer this question. Btw, a nice twist about Truecrypt's key derivation is that it does not store the used hash function in its header, so an attacker will have to try all of them. I think this does alleviate the low iteration count somewhat. –  Butters Jun 15 '12 at 17:48

1 Answer 1

This answer is just to add some other way to think about the question: if no flaw is found in symetric encription (i.e., in the algorithm you choose, like sha/whirlpool, or any other), there are physical limits on how far you can go to compute a brute-force attack over a 128 bits (16 character) password (or key).

Take a look at wikipedia to see how much energy it would require to compute such key space, and to verify that there's not enought energy available to do so.

share|improve this answer
    
Asside from the energy, what is the cost? Imagine we set up our password cracker on Amazon's cloud computing network and set it running. What would the bill from Amazon be for the computing time required to crack a 128 bits (16 character) password (or key)? –  Rincewind42 Jun 15 '12 at 4:09
    
@Rincewind42 - The only estimate that would be accurate would be the estimate that trys every single combination. Since that would take longer then Amazon will be on the planet it seems to even attempt to calculate. –  Ramhound Jun 15 '12 at 10:54
    
@Rincewind42 I don't think using amazon's cloud is a good idea. I'd rather go with ATI graphics cards that have good hashrate, similar to what's used in bitcoin mining. Or if you're a powerful attacker, use custom hardware. –  CodesInChaos Jun 15 '12 at 17:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.