Agilebits 1Password support and Design Flaw?

[epixoip]

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.

a lot of the sha1 optimizations do not apply for hmac-sha1. the remarkable speeds come from cutting the total number of transforms required by 75%. defenders have to do 4x more work than an attacker, and that is a design flaw which leads to remarkable cracking speeds.

[jpgoldberg]

a lot of the sha1 optimizations do not apply for hmac-sha1. the remarkable speeds come from cutting the total number of transforms required by 75%. defenders have to do 4x more work than an attacker,

Then I continue to remain confused.

Isn't that speed up due to unpacking HMAC from PBKDF2 and is independent of the Agile Keychain Format? That is, isn't that a general issue with PBKDF2? That is, isn't that just about computing SHA1(ipad ^ pwd) once only instead of once per PBKDF2 round?

[epixoip]

no, that's only half the issue.

the other half of the issue is that 2 blocks of hmac-sha1 are required to generate 320 bits, but only 1 block is required to validate the password. defenders have to do n*2 iterations to derive, attackers only have to do n iterations to validate.

[quinndupont]

This is great work, but I'm wondering what the significance here is (other than any optimization is a good optimization). If I am reading this all right, you've got the key down to 160bits, 2002 rounds at 3MH/S (on a relatively speedy dual GPU rig). If I have the math right (and damn, I probably don't), we're still looking at 10^27 years of cracking to exhaust the combinatoric space, right? Anyone care to offer a back-of-the-napkin analysis of the real-world implications (but, with non-idiot math, like mine)?

[epixoip]

you're assuming brute force, which no one would be dumb enough to do.

a more significant measurement: 3 MH/s means we can get through rockyou in 4.7s, rockyou + d3ad0ne.rule in 90m.

[jpgoldberg]

If I have the math right (and damn, I probably don't), we're still looking at 10^27 years of cracking to exhaust the combinatoric space, right?

Remember that unlike the passwords that 1Password saves for people, the Master Password has to be memorable and typable by humans. If one uses a diceware password phrase (as we recommend to 1Password users) then a three word pass phrase has a mean time to crack of 22 hours. A four word one has 19 years, five words is 150,000 years. After that it is millions of years.

In other words, this does change the kind of advice we have to give users. Please keep in eye on the AgileBits blog for more details.

[jpgoldberg]

no, that's only half the issue.

Right.

I'm sorry if I'm being dense. I see "half" of the issue being a general PBKDF2 issue that isn't specific to the Agile Keychain. The other "half" of the issue is our weird use of separate PBKDF2 runs to get the IV (not needed for cracking) and the encryption key (needed for cracking.)

The general PBKDF2 issue gives a 2x speed up. The Agile Keychain specific issue gives another 2x speed up. If we limit the term "design flaw" to the Agile Keychain specific stuff then that flaw leaves a 2x speed up.

If I'm (still) mistaken about this, I'd really like to know (and understand). I want to write this all up for the AgileBits blog.

[NVRGRLS]

took out my smartass comment.

I want to give kudos to the OP and to Jeffrey from agilebits. OP for obviously finding a great crack, Jeffrey for refreshing customer service and public response... imagine if OP cracked OSX filevault, would we see an apple employee come here with an explanation?

[Incisive]

Remember that unlike the passwords that 1Password saves for people, the Master Password has to be memorable and typable by humans. If one uses a diceware password phrase (as we recommend to 1Password users) then a three word pass phrase has a mean time to crack of 22 hours. A four word one has 19 years, five words is 150,000 years. After that it is millions of years.

In other words, this does change the kind of advice we have to give users. Please keep in eye on the AgileBits blog for more details.

What dictionary sizes are you assuming for the various passphrases?

I would also note that you appear to be ignoring Moore's Law in your time estimates, much like this old article did: http://www.garykessler.net/library/password.html .

[quinndupont]

Remember that unlike the passwords that 1Password saves for people, the Master Password has to be memorable and typable by humans. If one uses a diceware password phrase (as we recommend to 1Password users) then a three word pass phrase has a mean time to crack of 22 hours. A four word one has 19 years, five words is 150,000 years. After that it is millions of years.

In other words, this does change the kind of advice we have to give users. Please keep in eye on the AgileBits blog for more details.

What dictionary sizes are you assuming for the various passphrases?

Isn't the point of the OCLHashcat optimizations that these are being brute forced? Using a dictionary attack is a whole different ballgame.

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. If this is the case, then these time estimates are obviously wrong (or things are obviously broken). (What kind of security would a 7-character password offer then? Mere minutes?)

The whole point of using PBKDF2 is that it is key-stretching. You simply aren't attacking a password that has been straight SHA hashed. It sounds like these optimizations have removed a bunch of the key-stretching in PBKDF2, leaving in the words of the OP:

Instead of calculating a 256 bit key in the PBKDF2, we just need to calculate 128 bit. Since SHA1 gives us 160 bit, we can save exactly twice the number of calls to sha1 transform. This way I was able the reduce the calls to SHA1 transform from 8000 to 2002

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

Here's a useful discussion (showing the futility of brute forcing even relatively weak keys): http://security.stackexchange.com/questi...-are-expos