Brain Wallet standardization

[Pieter Wuille]

Nice to hear you are on this as well!
Create a human-rememberable output from 256- or even 512 bit randomness? I dont believe this is doable in that way. The human-languages-keyspace would be too small or the resulting token ridiculously long. You could brute-force many random keys until you find one which has a corresponding rememberable token. But this would be no different to, for example, hash a human-rememberable token and use the hash as a pseudo-random key..

I think you misunderstood me. Internally, the scheme uses 512-bits keys (so its master is this large), but as secp256k1 (the elliptic curve used by bitcoin) has only (a bit more than) 128-bit security anyway, there is no need to use (much) more entropy for generating the master. One possibility is using master=SHA512(seed), where seed is a randomly generated 128 to 256 bit value. This seed could be converted to (or generated from) a human-readable string, if a nice standard for such a conversion can be agreed upon.

[1714610109]

1714610109

[1714610109]

1714610109

[1714610109]

1714610109

[1714610109]

1714610109

[1714610109]

1714610109

[DeathAndTaxes]

I don't think standardization is required because things like the key derivation function, parameters, rounds, and salt AREN'T SECRETS.  The important thing is to make sure they are well documented and stored in a variety of locations.

There should be sufficient documentation that the wallet could be recreated from scratch as summing the author, all his files, and all his work product are all lost.

[Pieter Wuille]

Standardization is not intended to make public parameters implicit... it is intended to make its format compatible between different implementations.

[Ente]

However, it might be a good idea to write down how exactly the wallet was created. So the wallet could be recreated later, or even the program could be recreated to create the same wallet with the same passphrase.

Of course, the whole point is to not have a wallet, but a passphrase in memory. No idea where to write the instructions "how to recreate the wallet" in that case ;-)

Oh, I know! If its a standard, and all clients/services use the same way to create the wallet? duh!

Ente

[DeathAndTaxes]

Of course, the whole point is to not have a wallet, but a passphrase in memory. No idea where to write the instructions "how to recreate the wallet" in that case ;-)

Take a step back.  The reason for a brain wallet isn't just to avoid writing "something" down.  It is to avoid writing a SECRET down.  Once a secret is written down it can be compromised or lost.  

The implementation isn't a secret and having that "written down" (as in drop a copy in your google docs folder, drop box, filing cabinet, email it to yourself, etc) doesn't represent a risk of compromise.

A universal standard is like a utopia.  It probably will never happen.

I have used this cartoon before but it is (sadly) accurate.


Maybe a universal standard will happen but I honestly doubt it.  There will always be differing opinions between authors on implementation aspects.  An interim goal would be to push that all deterministic wallets provide specific details (not code) on the entire process ("secret" -> set of private keys) in plain text format for archiving which would make reconstruction without any access to current code possible.  That would provide at least some level of disaster recovery in the event no existing wallet is compatible.

[paraipan]

watching...

[beckspace]

gmaxwell convinced me that it is not safe to let users chose their passphrase.
this is why the passphrase used by Electrum is generated by the software.
it has 128 bits of entropy plus key stretching.

A kid's question:

A kid (9 years old) asked me why he can't make a long passphrase just repeating one letter, and I coudn't answer properly.

Example: kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkbitcoin
(30 k's and the word bitcoin)

[Ente]

gmaxwell convinced me that it is not safe to let users chose their passphrase.
this is why the passphrase used by Electrum is generated by the software.
it has 128 bits of entropy plus key stretching.

A kid's question:

A kid (9 years old) asked me why he can't make a long passphrase just repeating one letter, and I coudn't answer properly.

Example: kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkbitcoin
(30 k's and the word bitcoin)

As long as noone knows this "password generation scheme" (because it is the standard or someone watched me typing one key three dozen times and counting to 30) it doesnt make a worse password than another 37 random small-letter password.
You can either attack with a dictionary, permutations of words from a dictionary, or every combination through bruteforce. 30*k+bitcoin will only be found with brute-force, I would say.
Oh, but there may be funny details in your *implementation*. Like the old windows passwords as well as icq passwords would truncate after 8 letters.. ;-)

And, to add another heresy: I prefer to choose a long, strong password, and barely change it at all. Some of them I use for years now. If its only used for one login/website, I see no reason to change it at all, ever.

edit: I like that kid. Please buy it icecream and give it a hug.

Ente

[gmaxwell]

As long as noone knows this "password generation scheme" (because it is the standard or someone watched me typing one key three dozen times and counting to 30)

But I do know the generation scheme:  Ask a human to generate a secure password.

This is something humans are not good at and so they are prone to doing things like ... picking passwords with a repeated character (or, alternatively completely avoiding repeated characters). For example, here are some of the cracked mtgox passwords (all except the Us were using the more secure freebsd crypt scheme): uuuuuuuuu, ggggggggggg, 999999999q, qqqqqq123, 111111111a, 999999999, 88888888, 99999999.

Uniformly probable uncertain length between 1-33 adds only 5 bits of entropy to the repeated character model.   Meaning that if you're already doing "every character repeated" (which is obviously a useful model which cracking tools already include) searching all of those lengths only increases your workfactor by 32.

[ThomasV]

WARNING
A new website popped up, that lets users generate addresses from their Electrum or Armory seed: http://brainwallet.org/

It is not clear who created that website.
I previously thought it was Joric, but he said he is not the author.

After a quick inspection, the javascript does not send your seed to a remote server.
However, nothing guarantees that the server will always send you the same javascript

In other words: this could very well be a phishing attempt.
If you ever used that website, move your funds to a new wallet immediately!

[ThomasV]

addendum to my previous post:
there is evidence that some people are "mining" for password-generated bitcoin addresses;
in other words, they are using the brute force of their computers in order to discover passwords.

if you use a deterministic wallet such as Electrum, do not trust yourself for inventing a seed that is complex enough; use the seed provided by the software.

[calian]

One good little piece of standardization I'm seeing that has developed is that both brainwallet.org and bitaddress.org use SHA256(passphrase) for their single address generation. Now we just could use some standardization for the deterministic wallet idea. I really don't like how Electrum won't let you make your own passphrase.

[Mike Jones]

I really don't like how Electrum won't let you make your own passphrase.

Is the argument really along the lines of "You're too stupid to create your own password."?

[rjk]

I really don't like how Electrum won't let you make your own passphrase.

Is the argument really along the lines of "You're too stupid to create your own password."?

Yes, because entropy is hard for most people to understand.

[mb300sd]

My approach:

PrivKey1: sha256 x5 "my long passphrase"
PrivKey2: sha256 x6 "my long passphrase"
PrivKey3: sha256 x7 "my long passphrase"
PrivKey4: sha256 x8 "my long passphrase"
etc.

I might forget that I started at x5 at some point, but it doesn't matter much.

[Ente]

Coincidently, I "tested" my passphrase some days ago, and could not come up with the details. Which order? Capitals? All capitals? Spaces in between?
I finally wrote down all combinations and tried them in a script. Yay for linux scripting. Not yay for how difficult it is to esthablish a secure solution intended for years and decades.. ;-)

Ente

[molecular]

My approach:

PrivKey1: sha256 x5 "my long passphrase"
PrivKey2: sha256 x6 "my long passphrase"
PrivKey3: sha256 x7 "my long passphrase"
PrivKey4: sha256 x8 "my long passphrase"
etc.

I might forget that I started at x5 at some point, but it doesn't matter much.

PrivKey1: sha256("my long passphrase1")
PrivKey2: sha256("my long passphrase2")
PrivKey3: sha256("my long passphrase3")
PrivKey4: sha256("my long passphrase4")

anything wrong with that?

[flipperfish]

My approach:

PrivKey1: sha256 x5 "my long passphrase"
PrivKey2: sha256 x6 "my long passphrase"
PrivKey3: sha256 x7 "my long passphrase"
PrivKey4: sha256 x8 "my long passphrase"
etc.

I might forget that I started at x5 at some point, but it doesn't matter much.

This is probably a bad solution, because as soon as sha256 x5 "passphrase" is known to the attacker, he gains knowledge of the other private keys, too.

In general I agree to what is said here: It's bad, if the software generates the password for you, for this reasons:

• Hard to remember
• User can not be sure, that the password is really genrated randomly: If it were, the software could take the self invented passphrase as (part of the) input as well.

The question is: How much bits of entropy are needed for a password to not be easily crackable by brute-force? How long does it take to try one possibility?
If you "mine" for private keys (by choosing random), there is always the chance to find one. But this chance is equal for all schemes for generating the private key.

Btw.: Entropy is not everything. If you generate your password from many words, which occur in a dictionary and the attacker knows that, all the entropy of single characters is worthless, because the attacker can guess your password with a wordlist.

[Ente]

The question is: How much bits of entropy are needed for a password to not be easily crackable by brute-force? How long does it take to try one possibility?
If you "mine" for private keys (by choosing random), there is always the chance to find one. But this chance is equal for all schemes for generating the private key.

Btw.: Entropy is not everything. If you generate your password from many words, which occur in a dictionary and the attacker knows that, all the entropy of single characters is worthless, because the attacker can guess your password with a wordlist.

You surely know "correct horse battery staple":
https://xkcd.com/936/

The there calculated 550 years (instead of 3 days) do *not* come from "attacker tries every possible combination of small letters up to 25 letters (that would be much much more than 550 years), but precisely assuming what you did, that the attacker has a dictionary with one-, two thousand words where he shuffles them to different combinations of four words.

I couldn't really believe it when I first thought about it, and found much more detailed calculations to exactly this example somewhere.

Ente

[DeathAndTaxes]

Btw.: Entropy is not everything. If you generate your password from many words, which occur in a dictionary and the attacker knows that, all the entropy of single characters is worthless, because the attacker can guess your password with a wordlist.

BTW entropy is everything you are just calculating it wrong.   If the passphrases comes from a dictionary list (and the person designing it will ASSSUME the attacker knows it) the entropy is (words in list)^(number of words)

i.e. if you have a word list of 5,000 words and generate a passphrase which consists of 10 of them randomly it would have

5000^10 ~= 2^122 or 122 bits of entropy.  (that assumes selection with replacement, too lazy to did the more common selection w/o replacement).