(04-16-2013, 04:46 PM)atom Wrote: [ -> ]The PBKDF2-HMAC-SHA1 part is what makes the entire calculation slow. For each iteration of PBKDF2-HMAC-SHA1 you call 4 times the SHA1 transform. But this is only to produce a 160 bit key. To produce the required 320 bit key, you call it 8 times.
Our mistake, then, was in failing to realize how PBKDF2 degenerates when you ask it for 32 bytes but just give it the 20-byte SHA1 to work with.
@atom: what is the maximum password length supported for this format? 15 as usual?
(04-17-2013, 05:35 AM)quinndupont Wrote: [ -> ]Isn't the point of the OCLHashcat optimizations that these are being brute forced? Using a dictionary attack is a whole different ballgame.
No way! Brute force has exponential time complexity; GPUs help a little, but not much in the grand scheme of things. Mask attacks and markov mode help quite a bit, but straight brute force is a last resort. Dictionary and rule-based attacks are where the real action is. Have a look at all the various attack modes that Hashcat supports:
https://hashcat.net/wiki/#attack_modes
(04-17-2013, 05:35 AM)quinndupont Wrote: [ -> ]And as to the "master password", I'm not sure what jpgoldberg means by "three word" passwords, but I assume this to mean many characters, not just three characters.
He's referring to using a three-word passphrase, such as "hashcatisawesome."
(04-17-2013, 05:35 AM)quinndupont Wrote: [ -> ]If I understand this correctly, the brute force attack is against a 128 bit (or maybe 160 bit) key (either way, no matter). Even if there was only one iteration (not 2002) you're still looking at 2^128...
No... we're not brute forcing the key, we're brute forcing the input that was used to derive the key. In terms of brute force, an eight character password for example would be 95^8. Except none of us here would be ignorant enough to use brute force with this algorithm, because even with the optimizations, it's still too slow for that.
You seem to have some pretty big misconceptions about password cracking, so I would suggest doing a bit of reading on how password cracking actually works.
Just wanted to post some new results:
I've ported to GPU code from OpenCL to CUDA. My NVidia gtx560Ti (budget card) is doing 206 KH/s.
UPDATE: Beta-Users reporting the gtx580 is running at 365.2 KH/s
Beta-Testers: A new beta-version (beta5) for Linux and Windows for both AMD and NVidia GPU's. Its up in /beta and also contains the new Samsung Android PIN/Password cracking hash-mode 5800.
@epixoip: Can you please add a TRAC Ticket for the change of the units to KH/s (kilohashes), MH/s (megahashes), GH/s (gigahashes), etc? I like the Idea.
@jpgoldberg: If you're interessted I can add you as a beta-tester.
atom, I'm impressed as never before
Great job !
atom, you are doing the AES decryption on GPU? I guess you are using the table-based approach (such as what OpenSSL does and not what the AES sample from AMD APP SDK does). Do you store the expanded key in local memory or you are doing that on-the-fly? Asking about that because AES decryption is funny if you are doing the key scheduling on-the-fly, for some time I thought that would be impossible, but it is possible and quite feasible, you can even "pre-cache" some data to save some ALU operations on each round.
First, let me say that this has been a great discussion, and I'd like to thank Atom for the choice to branch out into some of the more interesting formats that aren't pure hashes!
Second, regarding passphrase passwords, people need to be warned to be careful of the words they choose - first and foremost, people should check to make sure at least one of their words isn't on lists like the
https://www.englishclub.com/vocabulary/co...s-5000.htm list of the top 5000 english words, and that's a bare minimum. For instance, "everything experience development federal" is four words, but they're all in the top 500 most common words, which, against an attacker using a Combinator attack (hashcat-utils!) is a keyspace of about 6E10... not very much, with over 2E6 seconds per month.
Third, on the Agile keychain format, I happen to use KeePass for the specific reason that I can change the number of iterations. Even on a smartphone, I choose millions of iterations; on a PC, tens of millions (and if it used AES-NI, I'd be using billions), specifically because I expected the cracking utilities to start using GPU, and you can always try to crack a file stolen before the technology improved. I'm also willing to wait a few seconds for a key to be decrypted, and I like the passphrase + file approach for a combination key, as well (though Truecrypt's multiple files is even better).
Speed for GTX Titan and a granny GTX 480:
Code:
Speed.GPU.#1...: 939.4k/s
Speed.GPU.#2...: 326.0k/s
Speed.GPU.#*...: 1265.4k/s