Existing research strongly suggests that deriving asymmetric keys from human-provided seeds (i.e. passphrases) and nothing else is strongly inadvisable.<p>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.<p>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.<p>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.
I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern:<p>If my passphrase gets compromised, I have to retire the keypair.<p>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.<p>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.
But wait… if the entire key is derived from the passphrase, if two people both choose the passphrase "password", would they not then get the same public and private keys? Can I not brute force people's private keys by taking millions of common passwords¹ and generating public keys from them, and then seeing which ones match my friends?<p>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.)<p>¹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"
This is a bad cryptosystem which will result in people being fucked. Take it offline. A serious known weakness of zxcvbn is that it will grossly overestimate the entropy of things like quotes, lines from songs, lines from movies, etc.<p>"the quick brown fox jumps over the lazy dog" has 111 bits of entropy according to zxcvbn.
I am not a cryptographer, but I'll offer some advice, if I may: don't let people choose a passphrase, generate one for them. People are very bad at creating good passphrases, but decent at memorizing a good one.<p>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.
MiniLock looks like a great option to introduce encryption to my non-technical friends. The alternative to minilock right now, for these users, is to do nothing.<p>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.
Relying on a passphrase only is not good enough. Enter it once on a compromised system and it's game over. Since your ID is tied to your passphrase you even have an issue and you will need to revoke your public key.<p>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.<p>That's why you need your ATM card, and why it has a PIN code.<p>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.<p>This approach focuses too much on the crypto aspects, and not enough on all the other things involved in building something that is secure.
Perhaps I'm missing something obvious, but I don't understand. What's so great about not having to store the key pair on disk? After all, this is a file encryption software. Its job is to store data on disk. In fact, it already adds a bunch of headers to every encrypted file. Why not just grab 128 random bits from /dev/urandom, make it the private key, encrypt it with the passphrase as all the other programs do, and stick the encrypted key in the header? It will only add a few dozen bytes to the header, which is peanuts.
Some times ago I created my own file encryption software using libsodium. It uses XSalsa20, hmacsha256, pbkdf. It hide password input on the terminal. It is really slow for large files (GBs)...<p><a href="https://github.com/viralpoetry/VPcrypt" rel="nofollow">https://github.com/viralpoetry/VPcrypt</a>
My favourite is that the Tweet has be come some standard of measure "fit inside less than half a tweet".<p>Not less than 70 characters; "less than half a tweet".