MiniLock – File encryption software that does more with less

I would use a secret key to encrypt the file, then encrypt the decryption key with each of the keys of those recipients, and add each (user ID, encrypted decryption key) to the file.

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.)
    }
  }

Note that in the above header, fileName is padded with the 0x00 byte until it reaches 256 bytes in length. This is done in order to prevent the discovery of the fileName length purely by analyzing an encrypted miniLock file’s header.

Small UX nitpick. You can't select the miniLock ID by double-clicking it. I think it was one of the reasons bitcoin used Base58 encoding.

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.

"the quick brown fox jumps over the lazy dog" has 111 bits of entropy according to zxcvbn.

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.