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

71–80 of 85 posts

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

#71

Post by andor »

lolbrainwallets wrote: post #28
sillysaurus3 wrote: post #22

Earlier quoted context omitted.

Hmm, I meant Scrypt. You can use Scrypt to encrypt files using a passphrase with no entropy restrictions. It doesn't use keys. People never raised this concern about Scrypt, and certainly didn't say people would get fucked for using it. What am I missing here? Why does Minilock warrant this outrage, but not Scrypt? https://www.tarsnap.com/scrypt.html

That tool generates a random salt, so passphrase cracking time is O(n) where n is the number of files being cracked vs O(1) for Minilock public keys. Additionally, encrypted files are generally still not "public", whereas Minilock public keys likely would be.

Assuming that all files are encrypted with the same passphrase, and you crack the passphrase, not the key generated from kdf(salt, passphrase), complexity is O(1) for Minilock as well.

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

#72

Post by diafygi »

chacham15 wrote: post #63
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.

Why not just store the salt with the data in the same file? Its not as though the program needs to maintain the files' binary compatibility with anything since the encrypted file isn't supposed to be readable by any other program other than the decryption program.

Actually, that's exactly what I proposed in my pull request[1], but it got rejected :(

[1] - https://github.com/kaepora/miniLock/pull/14

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

#73

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.

How about my proposed salting change? This would thwart a one-table attack.

https://github.com/kaepora/miniLock/pull/14

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

#74

Post by x1798DE »

akerl_ wrote: post #42
MichaelGG wrote: post #40

Earlier quoted context omitted.

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 rea…

Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. But that's not the case: https://github.com/dropbox/zxcvbn/issues/39 And as an attacker, I'm using my rainbow tables specifically to target the low hanging fruit. It gives me the best init…

>Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs.

I'm fairly skeptical of the ability of software to "ensure high-entropy passphrases". I don't think it's trivial to anticipate the entropy-lowering strategies that people will come up with in order to help them remember their passwords.

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

#75

Post by x1798DE »

Scaevolus wrote: post #45
infogulch wrote: post #39

Earlier quoted context omitted.

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?

The algorithm is [898, 537, 321, 205, 361] -> tidlotexidaifol -> "tidy lot existence daily following". The phrase is generated deterministically from the password, so it's no more secure than the previous steps. It's just a mnemonic to help remember the password. If by trigram you mean "3-letter word prefix", then yes, they are all equally likely. If you mean "group of 3 words", then no, they're very biased. "raccows…

Just to add to why you would or would not want to use the passphrase vs. the abbreviation - I've personally found that I find it much easier to actually type a password that consists of words, names or "nonsense words" generated by Markov chains (though not usually ones generated by letter frequencies).

I am often comfortable entering in a given password on a device on which I am not comfortable unlocking my password database (or entering my password database password + keyfile), but I usually have a device which does have my password database on it (phone, laptop, etc), so my application is "it doesn't have to be memorable, it just has to be something I'll enter without making a typo". For whatever reason, I find that entering in "tidlotexidaifol" would be harder for me to do accurately than "tidy lot existence daily following" or "tidylotexistencedailyfollowing".

That said, I like this approach, because some sites (like Bank of America, shockingly), restrict total password length, making a "very long password with relatively low entropy per character" approach infeasible.

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

#76

Post by polvi »

MiniLock looks like a great option to introduce encryption to my non-technical friends. The alternative to minilock right now, for these users, is to do nothing.

Even if we do not like it, right now state of the art on file sharing (for most of the non-technical world) is an unencrypted email attachment. MiniLock looks like it might be something I can install on my mothers (non-technical) computer so that I can send her a sensitive doc (copy of my tax return, for example). This crypto system is sufficient for that use case, and the alternative is to do nothing at all. The alternatives are not GPG, or RSA, or whatever, because outside of the technical community people have no idea how to use these things.

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

#77

Post by viralpoetry »

dchest wrote: post #59
viralpoetry wrote: post #57

Some times ago I created my own file encryption software using libsodium. It uses XSalsa20, hmacsha256, pbkdf. It hide password input on the terminal. It is really slow for large files (GBs)... https://github.com/viralpoetry/VPcrypt

Yours uses symmetric keys while miniLock is public-key crypto (crypto_box in NaCl terms).

Thank you for checking it out. I used it just myself, hence symmetric crypto only.

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

#78

Post by napoleond »

polvi wrote: post #76

MiniLock looks like a great option to introduce encryption to my non-technical friends. The alternative to minilock right now, for these users, is to do nothing. Even if we do not like it, right now state of the art on file sharing (for most of the non-technical world) is an unencrypted email attachment. MiniLock looks like it might be something I can install on my mothers (non-technical) computer so that I can send…

Exactly! When it comes to crypto apps, I have noticed two kinds of criticism: "This software is not built for the threat models that interest me" and "This software fails to properly address the threat model it claims to". Too often, commenters will act as though their critique belongs in the second category when it really belongs in the first.

(It's great to question the design goals of a project! But that's very different from saying that a project fails to do what it says. In this case, Minilock has very clearly accepted a threat model where, if the passphrase is compromised, that's the game. If you don't like that, don't use it!)

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

#79

Post by akerl_ »

x1798DE wrote: post #74
akerl_ wrote: post #42

Earlier quoted context omitted.

Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. But that's not the case: https://github.com/dropbox/zxcvbn/issues/39 And as an attacker, I'm using my rainbow tables specifically to target the low hanging fruit. It gives me the best init…

> Assuming they were actually keeping the contents of such wordlists out and actually ensuring high-entropy passphrases, we would be in an OK place, though still far removed from the security provided by randomly seeded ECC keypairs. I'm fairly skeptical of the ability of software to "ensure high-entropy passphrases". I don't think it's trivial to anticipate the entropy-lowering strategies that people will come up wi…

That's my point.

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

#80

Post by selimthegrim »

selimthegrim wrote: post #70
higherpurpose wrote: post #64

Earlier quoted context omitted.

Yeah, I wouldn't trust the TPM - certainly not from a Windows machine, and not even an Apple one after the recent revelations/research, which shows Apple tries to make the device secure against "regular" hackers, but very easy to access by Apple itself or the US government.

My current one is from atmel in 2008, before atmel quit making them, so I figure at least in this case I'm safe. I would probably not use a newer one if I was worried about TLAs though. As I am currently in the market for an MBP, where do I find this information about Apple TPMs?

My bad, Apple pulled them in 2006.
Post reply on HN