"the quick brown fox jumps over the lazy dog" has 111 bits of entropy according to zxcvbn.
key.length > 32 && zxcvbn(key).entropy > 100
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 32 Chinese characters is equivalent to a much longer English passphrase. I suggest lowering the key length requirement in this case. However, if my passphrase were in Arabic and my attacker knew it was likely to be in the Arabic alphabet, I'm not really entitled to the aforementioned Unicode bonus as the entropy drops to be similar to English (I think).
That said, the design decisions of zxcvbn do make sense for Dropbox and zxcvbn is not the crucial part of the minilock program (the crypto is). Users will always find a way to game the system and find the lowest possible entropy passphrase.
[0] https://github.com/kaepora/miniLock/blob/80aff2cdbcebf669fae... [1] https://github.com/dropbox/zxcvbn/issues/39 [2] https://github.com/dropbox/zxcvbn/blob/0a8b5b65a1864437eaac5...
Tarsnap has no restrictions on passphrase entropy whatsoever, yet people have no problem with Tarsnap. It's interesting that people are singling out Minilock for this feature. Is this the worst thing that can be said about Minilock?
EDIT: I accidentally said Tarsnap; I meant Scrypt.
Finally, whilst on my tablet, I noticed that it was as obvious as the "QWERTY" keyboard that showed up on screen. As a primarily-dvorak user, such a silly stroke of keys had not occurred to me and gave me a bit of a laugh.
This is because it is possible to attack large numbers of passphrases at once, and it is possible to harvest large numbers of targets from public databases of public keys.
Additionally, entropy estimation tools generally are not good at accounting for the fact that human behavior results in non-obvious biases and patterns in passphrase selection.
To see an example of this model failing on a large scale, look at the number of Bitcoin "brain wallets" that have been hacked, despite having apparently strong keys.
They work well for me, but some people dislike the abbreviation aspect. I'm investigating how to make a grammar-based engine (rather than bigram-based) for smaller data files and better phrases.
I also wonder if all possible trigrams are equally likely.
Question: why wouldn't you just use the passphrase itself as the password? Just because some websites limit password length?
Do you mean some kind of rainbow table attack, where you go through a dictionary and derive keypairs for every likely password? Then you could match any public key to the precomputed private key.
I'm not familiar enough with ECC to know if this is feasible, but it seems like an obvious weakness of the system.
Also, this simplifies setting up the attack in general. For example, attacking a bunch of keys based on random data + passwords is way harder than attacking keys based on just passwords, because for the former you must also have the random data (which presumably is not posted online in massive troves).
Of course, if your computer is cracked into, or your adversaries are using rubber-hose cryptanalysis, all bets are off. But this scenario is usually less probable than having your physical wallet or keychain stolen.
If my passphrase gets compromised, I have to retire the keypair.
That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old keyfiles are destroyed.
With MiniLock, if my passphrase is compromised the entire key material is compromised and I need to revoke the public key. But how do I revoke it? Do I tweet a message with the private key saying the public key is revoked? Will there be a centralized place to publish revocation messages? Efficient key revocation will be absolutely critical to this system and that's hard if the key distribution mechanism is tweets or some other ad hoc mechanism. This is one thing that PGP key servers really help with.
Am I wrong? Doesn't this seem much easier to brute force than a RSA key? (Presuming the private key hasn't been compromised; if it has, it's likely protected by a password, and then these two are about equal.)
¹accepting that some will get rejected because of "uses the zxcvbn library in order to impose a strict limit on the amount of detected entropy present in entered passphrases. miniLock will not allow passphrases that fall below the threshold of 100 bits of entropy"
[1] - https://github.com/kaepora/miniLock/blob/master/src/index.ht...
I say that because I don't trust the zxcvbn library. It underestimates the entropy of "aaaaa" as 7 bits [log(26 * 5)], not the correct value of 23 bits [log(26) * 5], for example. In this instance, it's to your advantage, but it doesn't inspire confidence in its other calculations.
Many years ago, people realised you need to rely on something more than knowledge (of a password/passphrase) alone. Pick any two out of {something you know,something you own,something you are}, the latter being implemented by biometry.
That's why you need your ATM card, and why it has a PIN code.
This is a step back into a world were security wasn't good enough. Security is more than crypto alone, it's mainly about keeping things secret. There are too many ways a passphrase could be compromised or discovered.
This approach focuses too much on the crypto aspects, and not enough on all the other things involved in building something that is secure.
The same is true of any heavily used system today. All systems: banks, credit cards, facebook, etc. use "something you know". "Something you own" has just recently picked up steam in the form of two factor authentication, but then again, how many people you know actually use that?
The only thing that I know of/heard of that might hold up against the type of attack that you describe is the behavioral keys: i.e. a key which is something about you that you dont necessarily know yourself, e.g. your style of chess, or your phrasing of sentences.
It's the same issue with PGP. Instead of capturing the password it captures the decrypted private key.
Bob sends public key to Alice. Alice uses public key to encrypt file and sends to Bob. ONLY Bob can decrypt the file (using his PRIVATE key).
If you sent a password, then anyone who intercepted it AND the encrypted archive would be able to decrypt it.
Am I understanding this correctly?
Even if we do not like it, right now state of the art on file sharing (for most of the non-technical world) is an unencrypted email attachment. MiniLock looks like it might be something I can install on my mothers (non-technical) computer so that I can send her a sensitive doc (copy of my tax return, for example). This crypto system is sufficient for that use case, and the alternative is to do nothing at all. The alternatives are not GPG, or RSA, or whatever, because outside of the technical community people have no idea how to use these things.
(It's great to question the design goals of a project! But that's very different from saying that a project fails to do what it says. In this case, Minilock has very clearly accepted a threat model where, if the passphrase is compromised, that's the game. If you don't like that, don't use it!)
Not less than 70 characters; "less than half a tweet".