Brain Wallet standardization

[cbeast]

Online and paper Bitcoin keys can be generated any which way, just as long as they are compatible with the blockchain. Many of the clients will now even import private keys in various formats. Brain Wallets are another story. The private key is dependent on the client that generated it. If the point of a Brain Wallet is to go dark, then you'll need assurance that generating your key is not traceable to a particular client. If you use your pass phrase in a different client, it will generate the wrong key to your cache. Is there a way to address some sort of standardization of the encryption method of Brain Wallets?

[Ente]

It depends on your approach. If all you want is a "one passphrase --> one privkey" approach, the original way was/is to simply hash the phrase with sha256.
The output is automatically a valid privkey. The pubkey can be calculated from that privkey.
You could use different hashing algos, or a combination of them (bitcoin uses at least ripemd160 and sha256), This would not generate more security, though. Sure, if someone knew the phrase (or has a wordlist), the exact combination of algos is an additional security, but computers have no big problem to test a dozen combinations of algos per phrase. The problem, of course, is to not only remember "mY Beetcoins are oh-so-safe!!1!" but now "mY Beetcoins are oh-so-safe!!1!" "sha256-ripemd160-sha256-sha256-ripemd160".
Now if your approach is to have one passphrase which generates more than one key, without compromising all keys when one key becomes public, I dont know. Clients already are able to do this, but I didnt read how they do it and if its the same way for all of them.

I am all for a standart! At the moment it should be relatively easy to have, there arent too many clients around and the community is quite centralized. So maybe its as easy as create a draft, find a good standart, ask client-authors and exchanges to implement it?
Oh, then get a standart of both (single-key and multi-key) approaches, and give them a name too! :-)

Ente

[Stardust]

openssl passwd -1 -salt "long phrase" | sha256sum

[Ente]

openssl passwd -1 -salt "long phrase" | sha256sum

You suggest using both a salt and a password there? If people have to remember both (and keep both secret), bitcoins will (more likely) be lost. The alternative, which is how I read your command first, would be to use the same salt for everyone as a default. Which would then be vulverable to rainbowtables.
So.. I think I prefer a passsword only. Or a salt only. Either way, just one string to be remembered.

Ente

[memvola]

Why use salt in this case? Just include the salt in the phrase.

Do you think we need a measure against brute force attacks? If not, sha256 should be fine, IMO.

Yes, a standard deterministic wallet generation scheme would be very useful. Are there any shortcomings of Electrum's?

[markm]

f you are going to rely upon using a computer to turn the passphrase back into a key anyway, then mightn't it be nice to make it take a bit of computing to do, like maybe take the hash of the hash of the hash, 10,000 or more deep? You'd memorise the phrase and also remember a favourite number or something, which, multiplied by 1000, or 10,000, or 100,000 or whatever, will be the number of times to iterate the hashing. This kind of multiple hashing is handy in general anyway for passwords, to make sure it takes a while per attempt. In act Unthinkingbit's bounty for a DeVCoin exchange explicitly requires the passwords have to be hashed at least 10,000 times (I think it was?) just so as to add this little bit of extra work anyone trying to brute force attack them will have to do.

-MarkM-

[Ente]

Yes, I agree to "do 10000 hashes of the phrase", but only if the number is given by the standard. Make it changeagle in "expert mode", if you like. But its trivial for a computer to generate 100000 times the hash of a phrase, and stop when one of the hashes matches a known address. It would not add security, but be another thing the user has to remember.

Ente

[CIYAM]

One way to do this (but does require you to remember 2 things) would be to have a pass phrase and a "pin" number (say 6 digits) where the pin is actually the number of times to hash the pass phrase.

As the main point of the PIN is just to harden the pass phrase from a brute force attack (where it is perhaps expected no information is known about whose pass phrase you are trying to crack) it doesn't really need to be so "random" (so could perhaps use birthdate or some other easily remembered number).

[memvola]

One way to do this (but does require you to remember 2 things) would be to have a pass phrase and a "pin" number (say 6 digits) where the pin is actually the number of times to hash the pass phrase.

You could've put those digits in the passphrase itself, which would increase the required iterations much more.

[ThomasV]

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.

[CIYAM]

You could've put those digits in the passphrase itself, which would increase the required iterations much more.

Good point - so perhaps the idea could just be to use something like name + bithdate + "x randomly chosen words" for the pass phrase.

[Ente]

One way to do this (but does require you to remember 2 things) would be to have a pass phrase and a "pin" number (say 6 digits) where the pin is actually the number of times to hash the pass phrase.

This adds almost no security.

You could've put those digits in the passphrase itself, which would increase the required iterations much more.

This adds security.

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.

I dont believe it is that bad. Display how any bits are used in the user's passphrase, maybe with an estimate of how quick it could be cracked.

I, however, would be very sceptical of a program/service where the passphrase is generated for me, and that passphrase gives immediate access to substancial value. I would either skim through the sourcecode, or drop that program right away.

Ente

[Ente]

You could've put those digits in the passphrase itself, which would increase the required iterations much more.

Good point - so perhaps the idea could just be to use something like name + bithdate + "x randomly chosen words" for the pass phrase.

exactly. And then you are at the beginning, again, where the user is responsible to create a secure passphrase, by which means he chooses. If everyone uses the same (given) scheme to generate the passphrase, it gets substantially more insecure..

Ente

[ThomasV]

I dont believe it is that bad. Display how any bits are used in the user's passphrase, maybe with an estimate of how quick it could be cracked.

yes, such "displays" exist. they are all wrong.

I, however, would be very sceptical of a program/service where the passphrase is generated for me, and that passphrase gives immediate access to substancial value. I would either skim through the sourcecode, or drop that program right away.

do you trust a program just because it lets you chose a passphrase?

btw, Electrum uses two secrets: a key generation seed (generated from the 128 bits passphrase) AND an encryption password chosen by the user

[memvola]

Well, apparently Electrum accepts a longer seed, so it's possible to sha256sum some pass phrase and create a deterministic wallet using that (edit: I used the "restore wallet from seed" function). Is Electrum's deterministic wallet generation algorithm documented somewhere? I'm sorry if this question is redundant.

[Pieter Wuille]

I've been working on a specification for deterministic wallets, to be included in the reference client (and Armory might adopt it as well). It is a bit more complex as it (optionally) supports multiple independent keypair chains, for different accounts and for public and non-public addresses.

It uses a 512-bit master key, but could very well be generated from a seed of only 128 or 256 bits of entropy (this is not yet specified). My preference would be having this part be generated randomly, to prevent weak user passwords resulting in entire wallets being exposed.If a nice standard can be agreed upon for converting such an amount of entropy to a human-readable (and hopefully rememberable) string, it could function as a very nice brainwallet.

The current draft can be found here.

[Ente]

I dont believe it is that bad. Display how any bits are used in the user's passphrase, maybe with an estimate of how quick it could be cracked.

yes, such "displays" exist. they are all wrong.

All wrong? So you say it is not possible to calculate the "strength" of a passsphrase in bits? Easy way: calculate the bits for a brute-force case, from length and keyspace. More clever way: Let the user enter a few additional infos, like "there are three real-world words in that phrase". I am not saying this is a must or necessarily worth the effort, but I don't agree "they are all wrong" at all.

do you trust a program just because it lets you chose a passphrase?

Of course "I can choose my passphrase" is not enough by itself for me to trust it. But in such a case I could (and might) skim through the sourcecode. If there is nothing hinting it transfers data through the internet as well as it seems reasonable it does what it states (i.e. use the installed openssl libraries to make hashes), I am reasonably sure. If then I dont find any warnings online, find some recommendations, and use it on a live-cd, I feel safe enough to trust it with some value.

If said program creates the passphrase (or a list of words), it doesn't have to transfer any data online. If there is a backdoor which makes the combination of the words non-random, it is close to impossible to find in the sourcecode as well as close to impossible to detect in the created passphrase. I would (and did) read through sourcecode. But I will definitely not make a statistical analysis of so-called random passphrases a program generates for me.

I will not trust any program/service/page/algo if I can not reproduce the output with a different method. Easy with pywallet and the like, I verify its working as intended with online sha256- and Hex/Base56 generators. If both ways lead to the same privatekey, I use the program in a secure (offline) way to create the privatekey I finally use for funds.

btw, Electrum uses two secrets: a key generation seed (generated from the 128 bits passphrase) AND an encryption password chosen by the user

Does that mean the user chooses a password and the seed is generated from this as well, or
the user chooses a password and gets an additional passphrase from the program?

Ente

[Ente]

I've been working on a specification for deterministic wallets, to be included in the reference client (and Armory might adopt it as well). It is a bit more complex as it (optionally) supports multiple independent keypair chains, for different accounts and for public and non-public addresses.

It uses a 512-bit master key, but could very well be generated from a seed of only 128 or 256 bits of entropy (this is not yet specified). My preference would be having this part be generated randomly, to prevent weak user passwords resulting in entire wallets being exposed.If a nice standard can be agreed upon for converting such an amount of entropy to a human-readable (and hopefully rememberable) string, it could function as a very nice brainwallet.

The current draft can be found here.

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

May I suggest KISS? :-)

Ente

[ThomasV]

Well, apparently Electrum accepts a longer seed, so it's possible to sha256sum some pass phrase and create a deterministic wallet using that (edit: I used the "restore wallet from seed" function). Is Electrum's deterministic wallet generation algorithm documented somewhere? I'm sorry if this question is redundant.

indeed, Electrum accepts any seed if you chose to use the "restore from seed" function;
this method lets you bypass its 128 bits generated seed.

sorry but there's no documentation. the code is simple to read, though

[ThomasV]

Does that mean the user chooses a password and the seed is generated from this as well, or
the user chooses a password and gets an additional passphrase from the program?

no, the seed is not generated from the password.
the encryption password is only used to encrypt your wallet.

To access your money, you need :
seed OR ( wallet file AND password )