4

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 encryption 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

Improve this question
3
  • Very similar to security.stackexchange.com/questions/12114/…
    – CodesInChaos
    Commented Jun 15, 2012 at 13:09
  • A try is more like 100k cycles, but truecrypt's iteration count is far too low IMO.
    – CodesInChaos
    Commented Jun 15, 2012 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
    Commented Jun 15, 2012 at 17:48

1 Answer 1

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

Improve this answer
4
  • 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
    Commented Jun 15, 2012 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
    Commented Jun 15, 2012 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
    Commented Jun 15, 2012 at 17:50
  • 1
    @Rincewind42 The cost is nothing if you're using stolen credit cards
    – ste-fu
    Commented Mar 28, 2018 at 11:56

You must log in to answer this question.

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