Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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?


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


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.


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.


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


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


There are 1024 trigrams, so 10 bits each. That's the same information density as random digits.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: