zxcvbn

Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. But that's not the case: https://github.com/dropbox/zxcvbn/issues/39 And as an attacker, I'm using my rainbow tables specifically to target the low hanging fruit. It gives me the best initial odds, and also the best return on any given hit: I'm way more likely to get more users per match for things in the common phrasebook, by nature of it being the common phrasebook.

Yeah use of zxcvbn is a problem. Minilock's key strength checking goes[0]: key.length > 32 && zxcvbn(key).entropy > 100 Firstly minilock allows the following: zxcvbn(". . . . . . . . . . . . . . . . ").entropy = 161.421 [1] Secondly this only really works for English. While they are used to being forced to use English passwords, we can't expect that speakers of other languages would like English passphrases. It also has heuristics making assumptions of how people choose passwords (e.g. l33tifying) which may be less valid for longer phrases than short passwords. zxcvbn uses all English word lists and keyboard layout and automatically gives you a Unicode bonus[2] if you use unexpected characters. If I write a sentence in Chinese, I have a high entropy. Here minilock actually penalises Chinese by adding the key.length > 32 requirement as