Live data from Hacker News

MiniLock – File encryption software that does more with less

minilock.io

51–60 of 85 posts

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

#51
post #42

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…

I don't get your point with your link. It says it cannot detect certain repeated character runs, or the word "password" in Morse code.

Basically you're arguing against memorizing the key. That means users are forced to keep a file around. It ignores the many cases where you don't want to have to maintain a file.

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

#52
post #43

Earlier quoted context omitted.

There's no difference between that and just requiring the user to use a longer password. Anyone trying to attack the system will just program their cracker to be more likely to try concatenating words together awkwardly in the password somewhere.

It's easier for humans to remember two distinct passwords with individual complexity requirements than one gigantic passphrase. By forcing the user to choose two passphrases which are then concatenated, the result is one gigantic passphrase that a cracker can't easily crack, yet is easy for humans to remember. It seems like this solves the problem of rainbow tables. A keylogger could still break this system. But if a…

I mean, you could just tell users to pick two sentences, if that's what you're after.

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

#53

The overview literally just sounds like encrypted archive files. How is this different from putting a password on a .7z or .rar file?

They aren't sending the PASSWORD in the clear, they're sending (effectively) a public key. Bob sends public key to Alice. Alice uses public key to encrypt file and sends to Bob. ONLY Bob can decrypt the file (using his PRIVATE key). If you sent a password, then anyone who intercepted it AND the encrypted archive would be able to decrypt it.

seems that how they generate the keys, it's basically the same. The same password would generate the same keys. Anyone who uses the same password would be able to decrypt data sent to anyone else using the same password.

Am I understanding this correctly?

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

#54
I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern:

If my passphrase gets compromised, I have to retire the keypair.

That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old keyfiles are destroyed.

With MiniLock, if my passphrase is compromised the entire key material is compromised and I need to revoke the public key. But how do I revoke it? Do I tweet a message with the private key saying the public key is revoked? Will there be a centralized place to publish revocation messages? Efficient key revocation will be absolutely critical to this system and that's hard if the key distribution mechanism is tweets or some other ad hoc mechanism. This is one thing that PGP key servers really help with.

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

#55

I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern: If my passphrase gets compromised, I have to retire the keypair. That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old key…

I actually approached Kobeissi with this point in the meeting in Noisy Square right after the talk, suggesting he integrate a TPM into his key management system (like how you can call out to one in Firefox for SSL with libpkcs5.so or some similarly named library). He responded that the specs were open enough that anyone could add that in. As to a centralized place your guess is as good as mine. Also can MacBook users even access their TPMs?

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

#56
Relying on a passphrase only is not good enough. Enter it once on a compromised system and it's game over. Since your ID is tied to your passphrase you even have an issue and you will need to revoke your public key.

Many years ago, people realised you need to rely on something more than knowledge (of a password/passphrase) alone. Pick any two out of {something you know,something you own,something you are}, the latter being implemented by biometry.

That's why you need your ATM card, and why it has a PIN code.

This is a step back into a world were security wasn't good enough. Security is more than crypto alone, it's mainly about keeping things secret. There are too many ways a passphrase could be compromised or discovered.

This approach focuses too much on the crypto aspects, and not enough on all the other things involved in building something that is secure.

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

#58
post #56

Relying on a passphrase only is not good enough. Enter it once on a compromised system and it's game over. Since your ID is tied to your passphrase you even have an issue and you will need to revoke your public key. Many years ago, people realised you need to rely on something more than knowledge (of a password/passphrase) alone. Pick any two out of {something you know,something you own,something you are}, the latter…

> Enter it once on a compromised system and it's game over.

It's the same issue with PGP. Instead of capturing the password it captures the decrypted private key.

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

#59

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

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

#60
post #33
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.

Use the tuple (email,passphrase). Still easy to remember and the email functions as a salt, and will prevent any rainbow attacks
Post reply on HN