Skip to content

Comment on MiniLock – File encryption software that does more with lessparent

Comments

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.

Exercise: This padding scheme will not hide the length of the file name as intended. Why?

AAAAAAAAAAAAAAAAA...

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.