2 ms·

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

by ajross 3y ago

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

codetrotter 3y ago
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 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 https://github.com/ctsrc/Pgen
- ryanatdistrust 3y ago
  It looks neat, I'll pass this along to the team and take a deeper look at it later.
  - sowbug 3y ago
    Also generating a BIP39 seed from https://iancoleman.io/bip39/ https://iancoleman.io/bip39/ and using as many words from the output as you want for your purposes.
- avnigo 3y ago
  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 https://github.com/avnigo/nodice-cli
- iraqmtpizza 3y ago
  dibs on joyous embolism outsider evasion mashed. this is my new password
  - bombcar 3y ago
    It’s better than your last one, hunter2
kmeisthax 3y ago
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".
- fbdab103 3y ago
  >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.
- ajross 3y ago
  > 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.
mkj 3y ago
Diceware has been round for ages to do this (2 decades+?) https://theworld.com/~reinhold/diceware.html 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 https://github.com/mkj/dice

by ajross 3y ago

codetrotter 3y ago

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 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 https://github.com/ctsrc/Pgen

ryanatdistrust 3y ago
It looks neat, I'll pass this along to the team and take a deeper look at it later.
- sowbug 3y ago
  Also generating a BIP39 seed from https://iancoleman.io/bip39/ https://iancoleman.io/bip39/ and using as many words from the output as you want for your purposes.
avnigo 3y ago
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 https://github.com/avnigo/nodice-cli
iraqmtpizza 3y ago
dibs on joyous embolism outsider evasion mashed. this is my new password
- bombcar 3y ago
  It’s better than your last one, hunter2

kmeisthax 3y ago

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

fbdab103 3y ago
>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.
ajross 3y ago
> 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.

mkj 3y ago

Diceware has been round for ages to do this (2 decades+?) https://theworld.com/~reinhold/diceware.html 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 https://github.com/mkj/dice