miniLock for Privacy & Auth? (Open, Secure, Audited, High-Level)

[ghost]

Hi folks,

This app looks amazing, I only discovered it today. :)

However, the deal-breaker for me is the absence of privacy. This could be fixed easily enough, especially considering you're based on JS: Just use miniLock!

miniLock is a high-level, well-abstracted encryption system designed for messaging and file encryption. The standard implementation is written entirely in JS already. It uses deterministic key generation using email addresses as unique but nonprivate salts and a passphrase that's validated for security using zxcvbn.

The cryptosystem created for miniLock uses NaCl (Networking and Cryptography Library) primitives, but constructs them in such a way that:

• Sender's identity is secret if you only have the ciphertext.
• Recipient number is visible, but recipient identities are secret.
• Either the sender OR the recipient can forge an authenticated message, but nobody else can. This means that for a sender:recipient pair, authentication is built-in and guaranteed, but messages remain repudiable as a sender can always claim the recipient forged a message from them.
• Public keys used for encryption are tiny; ~40 characters or less. There is therefore no need to separate IDs from keys (like "Fingerprints").
• File or message size is visible, but can be any length.
• File identity is secret, though validation hashes are present in the encrypted header so integrity is guaranteed. File-name is provided with the encrypted file, again encrypted and secret.
• Headers can be separated from encrypted file contents easily, and headers can therefore be updated to add recipients or "forward" files simply by sending a new header with instructions to fetch the ciphertext. This makes it efficient for storing and sharing large files without needing new storage for each new recipient.

Using this for encryption of both messages and files would provide authentication, privacy, and could help obscure the identities of people in a conversation. Detaching the file header for larger files or posts opens the possibility of storing immutable large files on a DHT and sending only updated headers to include new messaging participants. Storing local mappings of friends to keys is trivial because of the key size and simplicity. Sender, Recipient and message integrity auhentication gets baked in without needing signature schemes or MACs.

I feel that privacy is the huge missing piece in Friends, and would love to see it happen. Minilock is JS, Free/Libre, and lots of people may already have miniLock IDs they can port directly to Friends if able.

[max-mapper]

@cathalgarvey +1, only downside is that MiniLock doesn't have a well maintained library version. All the code is buried in the original google chrome app codebase in a relatively difficult to use format. However, this version might end up being usable: mjethani/miniLock-cli#1

[ghost]

I also wrote a Go implementation which can be transpiled to a JS library with gopherjs. I have been meaning to implement a nice streaming API but the existing one ought to be sufficient if loading contents into RAM is acceptable.

My implementation is missing passphrase entropy estimation however, which is a critical part of ensuring security of deterministic keys (because guessing your key is easy for an attacker, mitigated only by scrypt and entropy estimation). I'd love to add this feature, but possibly a shim and some gopherjs bindings to the zxcvbn library would see this feature enabled in JS if not in Golang.

On 2 November 2015 10:33:17 GMT-08:00, maxogden [email protected] wrote:

@cathalgarvey +1, only downside is that MiniLock doesn't have a well
maintained library version. All the code is buried in the original
google chrome app codebase in a relatively difficult to use format.
However, this version might end up being usable:
mjethani/miniLock-cli#1

---

Reply to this email directly or view it on GitHub:
#145 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.