[ajross]

> Of course, there is no way in hell you can actually make the human brain store enough entropy perfectly

Sure there is. Have horse batteries taught us nothing?

https://xkcd.com/936/

Don't confuse key length with entropy. A properly-scaled PBKDF remains secure with as little as 48 bits or so. Needless to say, though, a 32 bit time value is hardly a properly designed key derivation input.

[mkj]

Diceware has been round for ages to do this (2 decades+?) https://theworld.com/~reinhold/diceware.html

I made a little android app using it to generate passphrases, each word gives 13 bits. So 6 words is plenty for a disk encryption password at boot.

https://github.com/mkj/dice

[codetrotter]

This xkcd comic has been instrumental to me.

I wrote a command-line utility a couple of years ago that I use myself regularly to generate secure and memorable passwords

https://github.com/ctsrc/Pgen

With this tool you can also see how many bits of entropy the passphrase generation settings you are using will result in.

For example, generating a 5 word passphrase using the long wordlist

    pgen -l -n 5

will yield a passphrase like:

    joyous embolism outsider evasion mashed

And when we ask the tool for the entropy with these settings

    pgen -l -n 5 -e

it will tell us:

    Current settings will create passphrases with 64.62 bits of entropy.

And hey, if you have reason to not trust the randomness capabilities of the program or your computer guess what :)

My program supports the use of physical dice to generate your password.

Have a look, try it out yourselves :D

https://github.com/ctsrc/Pgen

[avnigo]

That’s excellent! I had the same idea I completed a few weeks ago in python trying to write it with the standard library and have it be easily auditable. You can check it out here if you want:

https://github.com/avnigo/nodice-cli

[ryanatdistrust]

It looks neat, I'll pass this along to the team and take a deeper look at it later.

[sowbug]

Also generating a BIP39 seed from https://iancoleman.io/bip39/ and using as many words from the output as you want for your purposes.

[iraqmtpizza]

dibs on joyous embolism outsider evasion mashed. this is my new password

[bombcar]

It’s better than your last one, hunter2

[kmeisthax]

I use these passwords all the time. However, you should keep in mind the text in the comic:

> (Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)

This is almost a sound assumption for most web services[1]. However, this is Bitcoin. The only thing the attacker has is your hash. And you're using a payments system which economically incentivizes the creation of ever-larger systems for brute-forcing hashes. The network's hash power as a whole is estimated to be around 331 exahashes per second, so 68 bits of entropy would take one second to crack.

Correct horse battery staple would be cracked in fractions of a second by the full network. Eight common words would take 12 days. If we go further to 12 words, then we do get reasonable levels of security, but I'm assuming hashrates stay constant forever which is a bad assumption. And 12 word passphrases will already be about as much of a pain to remember as the 'password policy compliant' passwords xkcd was railing against.

[1] The most likely attack is actually credential-stuffing, not brute-force. xkcd is assuming you already use separate passwords.

Related: The password hashes for the xkcd forums actually did leak and it turned out most people's passwords were "correct horse battery staple".

No, not four random words. I mean the literal text "correct horse battery staple".

[ajross]

> However, this is Bitcoin. The only thing the attacker has is your hash.

You're doing exactly the "confusing entropy with key length" thing I was mentioning above.

That's not the situation at hand. The entropy in question is the private key generation, it's not related to any SHA256 hash in the protocol. But you're right, if you were trying to generate symmetric keys using a 48 bit password expanded using SHA256 as a PBKDF that would be a disaster. But no software is doing that[1]. All you need to do is pull a key derivation function off the shelf and use it with recommended parameters. Really these have been stable, even bcrypt is still very solid.

Your question was essentially "can a human being remember enough entropy to secure a bitcoin wallet". And the answer is absolutely yes.

[1] What it was doing was even worse, of course.

[fbdab103]

>Related: The password hashes for the xkcd forums actually did leak and it turned out most people's passwords were "correct horse battery staple".

Not sure I would read too much into that. I am sure many people value the community there, but it it ultimately, a web forum around a web comic.