This is making the rounds on Twitter. I think the narrative is pretty unfair to 1Password, and that they're bending over backwards to seem reasonable and attentive†.

The problem as I understand it is that 1Pw runs PBKDF2-HMAC-SHA1 twice. 1Pw stores encrypted passwords using AES-CBC. It derives a 128 bit AES key from the first run of PBKDF2, and the 128 bit CBC IV from the balance of the first and the first bits of the second. Based on that design, it appears that 1Pw believed that the secrecy of the IV would contribute to the difficulty of cracking the encrypted blob, but of course it doesn't, because the trailing bytes of the blob are known plaintext and an attacker can use the key without knowing the IV to check if their password guess is right.

This is not a great design. But it's bad in a way that wastes cycles for users. The fact that 1Pw does extra PBKDF2 work that doesn't bind on attackers don't make 1Pw meaningfully weaker than any other app that uses PBKDF2, because it was already weird that they were tapping PBKDF2 twice to begin with. A more idiomatic use of PBKDF2 in this situation would be to tap PBKDF2 once, and then expand it (say with SHA2) to 256 bits. That design, which is totally reasonable and would not be the subject of a news story, would be equivalently secure to the "flawed" approach 1Pw took.

There is another problem with the construction 1Pw uses, which is that they chose PBKDF2-HMAC-SHA1. PBKDF2 with SHA hashes are among the easiest KDFs to crack on GPUs††, because SHAx was designed to be fast in hardware. 1Pw would have been much better off with scrypt, or even bcrypt (which is still a pain to implement in GPUs). But PBKDF2 is an industry best practice; to ding someone for using it while the rest of the world still uses "salted hashes" seems unreasonable.

What's happening here, besides the echo-chamber effect, is that the implementation of the brute force cracker for this particular encrypt blob is clever. In a rush to applaud cleverness, Twitter seems to have lept to the conclusion that "clever attack" means "vulnerable target". That's usually a correct assumption, but it isn't in this case.

Corrections more than welcome.

† They deserve some kind of medal for that, by the way, because I have no dog in this fight at all and I can't seem to shut up about the unfairness of it all.

†† It turns out there's a clever way to optimize this on a GPU by precomputing the ipad/opad in HMAC, too, which sped the cracker up.

I'm really disappointed about how shallow the discussions about Adapteva are, and have been, on HN.

To remind everyone, the H = hacker. This device is a godsend, as far as I'm concerned. For the first time ever I get fully documented access to compute array on chip. No the architecture wasn't designed for anything specific, like graphics, but that means I don't get bogged down in details I don't care about, like some obscure memory hierarchy.

The chip is plain, simple, low-power, and begging for people to have an imagination again. Stop asking what existing things you can do with it, ask what future things having something like this on a SoC would enable.

Also, you should really be thinking about the chip at the instruction level, writing toy DSL to asm compilers. Thinking along the lines of, oh yeah I'll use OpenCL so I can be hardware agnostic, is never going to allow you to see what can be possible with it. If you read the docs you'll see what a simple and regular design it is, perfect for writing your own simple tooling.

It's been a long time, but I feel like a kid again. Like when I first discovered assembly on my 8086. Finally a simple device I can tinker with, play, and wring performance out of.

Hallelujah! :)

Refreshingly honest and clear response from vendor:

http://hashcat.net/forum/thread-2238-post-13402.html#pid1340...

Here's a taste:

This design flaw is certainly real, and is one of the many reasons why we have started migrating to a new design. In short, when the Agile Keychain Format was designed (in 2008), we weren't aware of all of the various problems that come from using unauthenticated CBC mode encryption.

I could plead that we were in reasonably good company in making that kind of error, but as I've since learned, research in academic cryptography had been telling people not to use unauthenticated encryption for more than a decade. This is why today we aren't just looking at the kinds of attacks that seem practical, but we are also paying attention to security theorems.