Ups, made mistake, 3 million not 300 thousand. On 4 gpu's, I'm on phone, too small screen
Quote:In the new format that I mentioned, we actually make this last bit easier for you (by design).
Thx you, nice to collaborate w/ us.
Hey Jeffrey,
thanks for your honest words, I appreciate it. This thread somehow created more attraction that I've expected. Even more since the reason for me to add 1Password keychain was "just to learn" AES. Maybe I'll take a look at your new algorithm once its released but my priority is currently to add TrueCrypt.
About the speed, what you see is GPU not CPU. oclHashcat-plus runs on GPU's not CPU's. Due to the fact that oclHashcat-plus implements both the PBKDF2-HMAC-SHA1 and the AES-CBC on GPU there is actually 0% CPU load while cracking. I'm always trying to not overload the CPU with calculations so that the user is still able to use it for other tasks like watching a movie or playing games while cracking. This is why it's important for me to not create any load on CPU and oclHashcat-plus is currently the only cracker I know that is capable of this.
The speed is not 3.000 keys per second. It's 3.000.000 keys per second. Yes, 3 million! And its on 1000 iterations but it supports 10000 or 100000 or whatever. The iteration count is configured in the hashline. Speed and iteration count is linear. With 10000 iteration (current default) you would see 300.000 keys per second. I just decided to use 1000 since other benchmarks use 1000.
--
atom
(04-16-2013, 06:40 PM)atom Wrote: [ -> ]The speed is not 3.000 keys per second. It's 3.000.000 keys per second.
I guess congratulations are in order, but I hope you under stand that I was really really hoping that 3000k/s meant 3000 "keys/second".
So wow! That is impressive and definitely impacts the advice we need to give people.
Quote:And its on 1000 iterations but it supports 10000 or 100000 or whatever.
Thanks. Again, that gives me the ability to extrapolate in giving advice to people.
Thanks for your reply. We are (quite correctly) getting lots of questions about this and I want to be able to give people accurate numbers. There's a big difference between 3000 and 3000K.
Yeah I see what you mean. k/s can be easily misread as keys/sec. Maybe I should change this. If you want I can grant you access to the hashcat beta section so you can run it on your System. Currently I've only a AMD version but I can add an NVidia version, too.
@ChrisJohnRiley JtR was already exploiting this "flaw" for almost a year now. Nothing new here
@SecPhil @1Password @hashcat @solardiz
Additionally, JtR supports the latest "Cloud Keychain" format as well
and you can't beat those speeds
However, the speeds are awesome as usual. Good work atom!
After reading carefully I see that some of the optimizations are "new" (similar to what I did in O5LOGON format). Thanks for reporting them atom :-).
(04-16-2013, 04:46 PM)atom Wrote: [ -> ]But if you take a close look now you see these both mechanisms do not match in combination. To find out if the masterkey is correct, all we need is to match the padding, so all we need to satisfy the CBC is the previous 16 byte of data of the 1040 byte block. This 16 byte data is provided in the keychain! In other words, there is no need to calculate the IV at all.
"Yes, even with the wrong IV, only the first block is incorrectly decrypted. Rest of the blocks are fine. So, we just need to decrypt the last two blocks and then use padding oracle attack."
Correction: only the last block needs to be decrypted since we can substitute second last block as IV. heh, thanks for the lesson on CBC mode atom
--- This isn't a mailing list, keep your posts condensed so it doesn't shit up the thread. ---
(04-16-2013, 07:08 PM)atom Wrote: [ -> ]Yeah I see what you mean. k/s can be easily misread as keys/sec. Maybe I should change this.
I would recommend KH/s (kilohashes), MH/s (megahashes), GH/s (gigahashes), etc. A lot of people are already familiar with those units of measure since they are what is used to express hash rates in the cryptocurrency world.
I'm guessing that my earlier statements about John the Ripper crack rates was off by 100. I took "c/s" to mean "cracks per second" (I couldn't figure out what "c" was), but I'm guessing now that that was "hundreds per second". I've got to go back and make a lot of corrections in what I've written and told people.
(04-16-2013, 08:12 PM)jpgoldberg Wrote: [ -> ]I'm guessing that my earlier statements about John the Ripper crack rates was off by 100. I took "c/s" to mean "cracks per second" (I couldn't figure out what "c" was), but I'm guessing now that that was "hundreds per second". I've got to go back and make a lot of corrections in what I've written and told people.
c is candidates, but if JTR was displaying 100, then it was in fact 100.
(04-16-2013, 06:24 PM)jpgoldberg Wrote: [ -> ]I don't want to quibble about the meaning of the word "flaw",
With the help of time and discussions on Twitter, I see that yes there is a design flaw in the Agile Keychain key derivation that give the attacker a 1 bit advantage. I hadn't fully understand what atom was getting at. We use two PBKDF2 derivations (one for the IV the other for the key) and both will be needed to unlock the file.
But if your interest is only in verifying a password, you don't need to use the derivation for the key. So as
Marsh Ray explained it to me on Twitter
Quote:@jpgoldberg @hashcat @solardiz @jmgosney Defender must derive 2 blocks PBKDF2 (320 bits) but attkr can verify guess on only 1 block 160 bits
So OK. I get it now. It is a 1 bit flaw, but it is a flaw none-the-less.
The remarkable cracking speeds you have are far more due to what you've done with SHA1 in GPUs, but there is this design flaw as well.