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