But it's not a meaningful mistake, for two reasons: (1) they were being naive about how they used PBKDF2 to begin with (again: don't call it a second time to generate a key or a nonce) and the attack on their encrypted blobs still requires a brute force attack on the first output, and (2) we're discussing a minimal improvement on the complexity of an attack on their system, but there are much bigger improvements available to them if they move off PBKDF2.
But, really: deriving keys from PBKDF2 is just fine. If they had just used PBKDF2 (once!) to generate an AES key, and then used /dev/random to generate an IV, nobody would be talking about them right now.
(For what it's worth, a CTR nonce only gives you 64 more bits to play with).
* What do you mean that it requires a brute force attack on the first output? As I understand it, the attacker doesn't need to match all 256 bits of the derived key (only the first 128 bits), so the complexity is reduced by a lot. If those match, you can just run the KDF "properly" on the passphrase you guessed and get the rest of the bits, i.e. the IV. It thus weakens PBKDF2 to only need 2002 rounds of SHA, rather than 8000, and still allows you to decrypt the whole stream.
* If they used a random IV, they'd have to include it in the stream, which wouldn't really do anything more for security. The IV doesn't matter at all now either, but at least now it's secret. This attack doesn't use the key space of AES or the IV, though, so it's a bit moot.
* The CTR nonce would prevent the attacker from taking the 128-bit "shortcut", as they'd need all 256 bits of the derived key to decrypt the last block, which is the improvement I'm referring to.
Please correct me if I'm mistaken, I find crypto very interesting and would like to know where I'm wrong.
As I can see, they had various courses of action (don't take this to mean that they were remiss in securing their product, as they used best practices everywhere):
* Use AES-256, maybe deriving the key from a first run of the KDF and the IV from a second one, although that might also make for an attack.
* Use CTR mode. Unless I'm mistaken, the attacker would then need to guess both the key and the nonce to verify the block, which is significantly higher complexity.
* Re-encrypt the last block with the IV. This way, the attacker would have to decrypt with the other 128-bit key, and would need to know both to decrypt the last block.
* Pad the beginning, rather than the end. Or, since the string is of known length, just make it a multiple of the block size, and use no padding.
I'm really a crypto novice, though, so I might be completely mistaken. That said, it's a bit too bad that they didn't spend a bit of time thinking how they would crack their own product, they might have come up with this attack and mitigated it.
At any rate, running the KDF twice isn't a problem, unless you mean that it wastes CPU cycles for no good reason. In that case, I agree.