MiniLock – File encryption software that does more with less

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.

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.

[1] - https://github.com/kaepora/miniLock/blob/master/src/index.ht...

  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.

(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!)

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.

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.

Reading the linked page, that's exactly what they do (with a nonce to thwart various (differential, known plaintext, etc.) attacks)

The header itself is a stringified JSON object which contains information necessary for the recipients to decrypt the file. The JSON object has the following format:

  {
    senderID: Sender's miniLock ID,
    fileInfo: {
        (One copy of the below object for every recipient.)
        Unique nonce for decrypting this object (Base64): {
            fileKey: Key for file decryption (Base64),
            fileName: The file's original filename (String),
            fileNonce: Nonce for file decryption (Base64),
        }
        (Encrypted with shared secret derived from the sender’s
         private key and recipient's public key.
         Stored as Base64 string.)
    }
  }

The file would be encrypted using a symmetric encryption scheme (like AES), and then the key for decrypting it would be encrypted to each recipient. Adding an extra recipient then just involves encrypting the 128 or 256 bit key, which should be negligible increase in size.

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.