
MiniLock – File encryption software that does more with less - poolpool
http://minilock.io/
======
wyager
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 human behavior results in non-obvious biases and patterns in
passphrase selection.

To see an example of this model failing on a large scale, look at the number
of Bitcoin "brain wallets" that have been hacked, despite having apparently
strong keys.

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

~~~
infogulch
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?

~~~
Scaevolus
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.
"raccowsli" is as likely as "afrdisuti", but it will always generate the
mnemonic "race cow slipped", and never "racter cowslip slithered".

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

~~~
Scaevolus
You could use the phrase if you liked, but each word is only 10 bits of
entropy.

One nice thing about having a mnemonic for the password is that you don't have
to remember the words precisely -- you can modify the mnemonic to suit your
tastes as long as the prefix remains. I originally wrote it to generate
passwords that I have to enter frequently (e.g. sudo), so being short was a
goal.

I'm working on making actual passphrases with more entropy per word.

~~~
x1798DE
Yeah, I assume that you can just have a non-deterministic expansion which will
add some entropy per word to increase the entropy of the passphrase over the
abbreviated version, but my point was just that even if there's no increase in
_security_ by using the full passphrase, counter-intuitively, using the full
phrase would likely be more _convenient_ for me (and probably for many
others).

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

~~~
selimthegrim
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?

~~~
BuildTheRobots
Depending on who you're protecting against you might want to _really_ avoid
trusting your TPM.

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

~~~
selimthegrim
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?

~~~
selimthegrim
My bad, Apple pulled them in 2006.

------
deathanatos
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?
(Presuming the private key hasn't been compromised; if it has, it's likely
protected by a password, and then these two are about equal.)

¹accepting that some will get rejected because of "uses the zxcvbn library in
order to impose a strict limit on the amount of detected entropy present in
entered passphrases. miniLock will not allow passphrases that fall below the
threshold of 100 bits of entropy"

~~~
diafygi
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...](https://github.com/kaepora/miniLock/blob/master/src/index.html#L37)

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

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

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

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

~~~
sillysaurus3
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 an adversary has planted a
keylogger, they could've simply stolen your keyfile.

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

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

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

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

~~~
sillysaurus3
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](https://www.tarsnap.com/scrypt.html)

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

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

------
eliteraspberrie
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 your advantage, but it
doesn't inspire confidence in its other calculations.

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

~~~
eliteraspberrie
My mistake, zxcvbn uses that formula only for repetitions.

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

~~~
napoleond
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!)

------
simik
Small UX nitpick. You can't select the miniLock ID by double-clicking it. I
think it was one of the reasons bitcoin used Base58 encoding.

~~~
178
Afaik the main reason for base58 is making it impossible to mistake an 'I' for
an 'l', etc. Beeing able to always double-click is a nice added bonus, though.

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

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

The same is true of any heavily used system today. All systems: banks, credit
cards, facebook, etc. use "something you know". "Something you own" has just
recently picked up steam in the form of two factor authentication, but then
again, how many people you know actually use that?

The only thing that I know of/heard of that might hold up against the type of
attack that you describe is the behavioral keys: i.e. a key which is something
about you that you dont necessarily know yourself, e.g. your style of chess,
or your phrasing of sentences.

------
kijin
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 stick the encrypted key in the
header? It will only add a few dozen bytes to the header, which is peanuts.

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

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

~~~
woah
This comment is a perfect example of why encryption is mostly not used at all.
(Which is far worse than any given vuln). There's kind of a perverse all-or-
nothing attitude where the goal is to poke at any possible flaw in a system as
proof that it is completely worthless. What's wrong with there being different
tradeoffs between security and convenience? The insistence on all-or-nothing
solutions has resulted in the powers that be knowing almost everything about
almost everyone in our society, because almost no one wants to deal with the
trouble of "completely secure" encryption.

------
viralpoetry
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](https://github.com/viralpoetry/VPcrypt)

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

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

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

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

~~~
MrUnknown
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?

~~~
DiThi
If I send you an encrypted file with minilock, you won't know my password, and
I won't know yours, but you'll be the only one that can read it, and also
you'll be sure I've sent it and not anyone else.

Public key crypto has more advantages and users should understand the basics.
This introduction may be more clear (4:30)
[https://www.youtube.com/watch?v=vMiBwMHcSn0](https://www.youtube.com/watch?v=vMiBwMHcSn0)

Also I would only use their 7-random-words feature for passwords.

------
gdi2290
dat weissman score

------
edoceo
My favourite is that the Tweet has be come some standard of measure "fit
inside less than half a tweet".

Not less than 70 characters; "less than half a tweet".

