Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MiniLock – File encryption software that does more with less

minilock.io

Post reply on HN
Print view View original

11–20 of 85 posts

Re: MiniLock – File encryption software that does more with less

#11

Post by CHY872 »

rando289 wrote: post #9
lolbrainwallets wrote: post #8

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.

It is in a "a feedback period", exactly so they can get the feedback like you just gave. So get off your high horse about taking things down.

Not really. The feedback period is for things like UX etc - this essentially makes the software (as usual for these homebrew efforts) much less secure than you think it is. When the primary reason that this software is at all secure is that it enforces a minimum entropy, if there's a bug in that then no one should use the software.

Re: MiniLock – File encryption software that does more with less

#12

Post by ff7c11 »

kijin wrote: post #10

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…

I think so you can use it from any computer anywhere with just the passphrase to derive the key and don't need to carry and secure a file.

Re: MiniLock – File encryption software that does more with less

#13

Post by capnrefsmmat »

wyager wrote: post #5

Existing research strongly suggests that deriving asymmetric keys from human-provided seeds (i.e. passphrases) and nothing else is strongly inadvisable. 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. Additionally, entropy estimation tools generally are not good at accounting for the fact that h…

> This is because it is possible to attack large numbers of passphrases at once

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.

Re: MiniLock – File encryption software that does more with less

#14

Post by Scaevolus »

wyager wrote: post #5

Existing research strongly suggests that deriving asymmetric keys from human-provided seeds (i.e. passphrases) and nothing else is strongly inadvisable. 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. Additionally, entropy estimation tools generally are not good at accounting for the fact that h…

I've been working on generating memorable passphrases with provable entropy: http://rmmh.github.io/abbrase/

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.

Re: MiniLock – File encryption software that does more with less

#15

Post by ff7c11 »

lolbrainwallets wrote: post #8

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.

Yeah use of zxcvbn is a problem. Minilock's key strength checking goes[0]:

  key.length > 32 && zxcvbn(key).entropy > 100
Firstly minilock allows the following: zxcvbn(". . . . . . . . . . . . . . . . ").entropy = 161.421 [1]

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

Re: MiniLock – File encryption software that does more with less

#16

Post by ff7c11 »

Scaevolus wrote: post #14
wyager wrote: post #5

Existing research strongly suggests that deriving asymmetric keys from human-provided seeds (i.e. passphrases) and nothing else is strongly inadvisable. 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. Additionally, entropy estimation tools generally are not good at accounting for the fact that h…

I've been working on generating memorable passphrases with provable entropy: http://rmmh.github.io/abbrase/ 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.

Oooh I like this a lot. Very clever. How many trigrams do you actually choose from?

Re: MiniLock – File encryption software that does more with less

#17

Post by sillysaurus3 »

lolbrainwallets wrote: post #8

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.

Please don't use language like "People will get fucked" when critiquing a cryptosystem. HN is better than that.

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.

Re: MiniLock – File encryption software that does more with less

#18

Post by lolbrainwallets »

sillysaurus3 wrote: post #17
lolbrainwallets wrote: post #8

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.

Please don't use language like "People will get fucked" when critiquing a cryptosystem. HN is better than that. 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.

Tarsnap does not allow anyone who has your public key to attempt to crack your paraphrase. Minilock does, and in fact you can load all public keys into a bloom filter and crack them simultaniously with nearly the same speed as a single key. The design of this system is simply irresponsible. Saying people will be fucked is entirely appropriate here.

Re: MiniLock – File encryption software that does more with less

#20

Post by akerl_ »

ff7c11 wrote: post #12
kijin wrote: post #10

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…

I think so you can use it from any computer anywhere with just the passphrase to derive the key and don't need to carry and secure a file.

If you're entering your passphrase on systems you don't control, it's already game over for that passphrase.
Post reply on HN