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

31–40 of 85 posts

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

#31

Post by eliteraspberrie »

lolbrainwallets wrote: post #29
eliteraspberrie wrote: post #27

I am not a cryptographer, but I'll offer some advice, if I may: don't let people choose a passphrase, generate one for them. People are very bad at creating good passphrases, but decent at memorizing a good one. I say that because I don't trust the zxcvbn library. It underestimates the entropy of "aaaaa" as 7 bits [log(26 * 5)], not the correct value of 23 bits [log(26) * 5], for example. In this instance, it's to yo…

zxcvbn has problems but your example is backwards. "aaaaa" gets (as it should) low entropy because it is a single repeated character. It is more likely to be used than "rqntd". The major limitations are that it is worthless for estimating entropy of passphrase (which is what it's being used for here) and words not in its dictionary (non english).

My mistake, zxcvbn uses that formula only for repetitions.

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

#32

Post by akerl_ »

diafygi wrote: post #30
deathanatos wrote: post #26

But wait… if the entire key is derived from the passphrase, if two people both choose the passphrase "password", would they not then get the same public and private keys? Can I not brute force people's private keys by taking millions of common passwords¹ and generating public keys from them, and then seeing which ones match my friends? Am I wrong? Doesn't this seem much easier to brute force than a RSA key? (Presumin…

Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.ht...

Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.

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

#33

Post by diafygi »

akerl_ wrote: post #32
diafygi wrote: post #30

Earlier quoted context omitted.

Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.ht...

Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.

Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.

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

#34

Post by sillysaurus3 »

diafygi wrote: post #33
akerl_ wrote: post #32

Earlier quoted context omitted.

Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.

Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.

What about making the user choose two passphrases, which are concatenated together by the tool? Cracking a single passphrase may be easy, but cracking two concatenated passphrases is significantly harder.

E.g. password 1: "the quick brown fox jumps over the lazy dog"

Password 2: "jack be nimble jack be sick"

Final result, used to derive a keyfile: "the quick brown fox jumps over the lazy dogjack be nimble jack be sick"

Notice how "quick" was switched with "sick" in the last word. Now there's no pattern that can be easily cracked. If we force a user to explicitly do something like that, then this can still work.

That example was chosen intentionally to be weak. It shows that even with two relatively weak passphrases, the result is still somewhat strong. If we add extra requirements on top of that, such as forcing the user to use numbers and capitalizations, then the result should be sufficiently unique.

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

#35

Post by akerl_ »

diafygi wrote: post #33
akerl_ wrote: post #32

Earlier quoted context omitted.

Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.

Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.

What makes dealing with key pairs hard for the lay user?

If the issue is "they have to transport them to use the crypto on systems other than their own": We should not be teaching lay-users (or non-lay-users) to enter passphrases or use private keys on untrusted systems.

For using multiple trusted systems, having the client software support multiple keypairs (like OpenSSH) or providing an easy way read the key off removable media (like an encrypted thumb drive) are great.

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

#36

Post by akerl_ »

sillysaurus3 wrote: post #34
diafygi wrote: post #33

Earlier quoted context omitted.

Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.

What about making the user choose two passphrases, which are concatenated together by the tool? Cracking a single passphrase may be easy, but cracking two concatenated passphrases is significantly harder. E.g. password 1: "the quick brown fox jumps over the lazy dog" Password 2: "jack be nimble jack be sick" Final result, used to derive a keyfile: "the quick brown fox jumps over the lazy dogjack be nimble jack be sic…

No, because then the person generating their table just takes that into account. It's slighly harder, but not noticeably so compared to how secure it needs to be.

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

#37

Post by wyager »

capnrefsmmat wrote: post #13
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.

Yeah, the fact that breaking this cryptosystem is essentially equivalent to attacking unsalted passwords means that an attacker can save a lot of work.

Also, this simplifies setting up the attack in general. For example, attacking a bunch of keys based on random data + passwords is way harder than attacking keys based on just passwords, because for the former you must also have the random data (which presumably is not posted online in massive troves).

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

#38

Post by sillysaurus3 »

akerl_ wrote: post #36
sillysaurus3 wrote: post #34

Earlier quoted context omitted.

What about making the user choose two passphrases, which are concatenated together by the tool? Cracking a single passphrase may be easy, but cracking two concatenated passphrases is significantly harder. E.g. password 1: "the quick brown fox jumps over the lazy dog" Password 2: "jack be nimble jack be sick" Final result, used to derive a keyfile: "the quick brown fox jumps over the lazy dogjack be nimble jack be sic…

No, because then the person generating their table just takes that into account. It's slighly harder, but not noticeably so compared to how secure it needs to be.

It seems like as long as the complexity of the passphrase is sufficient, then a rainbow table can't be effective. For example, a 128-bit random AES key is a kind of passphrase that's generally not susceptible to a rainbow table attack (though it's very hard for humans to remember). So the problem here is, how do you force the user to make their passphrase sufficiently complex?

Passphrases also don't protect against keyloggers, which is a downside of this approach.

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

#39

Post by infogulch »

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.

Nice! I like this methodology.

I also wonder if all possible trigrams are equally likely.

Question: why wouldn't you just use the passphrase itself as the password? Just because some websites limit password length?

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

#40

Post by MichaelGG »

akerl_ wrote: post #32
diafygi wrote: post #30

Earlier quoted context omitted.

Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.ht...

Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.

Please enlighten us on how to generate rainbow tables for passphrases. Assuming they use a lower bound of 6 bits per character, a 100 bit phrase is 46 characters long.

Off the top of my head, I'd use a book of quotations, popular lines from movies, etc. And try to hit common permutations of each. So there's a bit of low hanging fruit. But that could be detected when they generate their key.

Remember, salt doesn't really prevent anyone from using "password" or the first line of Billie Jean.

Post reply on HN