0

Brainwallet is a well-known tool that lets you generate an address from a passphrase. I think Brainwallet just performs a single SHA256 hash on the passphrase to get the 256-bit private key of the address.

Is there a BIP-standard formulated for this calculation?

Now that HD wallets are making there way to become mainstream, I think it is useful to have a standard to generate an HD wallet from a passphrase. Electrum and CarbonWallet seem to already have implemented HD wallet generation from passphrase and they are using 100,000 rounds of SHA256, which sounds already a much safer process than a single round.

The original BIP0032 that defines HD wallets doesn't define a way to generate them from passphrases (and it shouldn't), so maybe it is a good idea to make a separate BIP for this purpose if it does not already exists.

I want to be able to switch between wallet apps just taking my master key with me. Or for HD wallets, f.e. use a different wallet for watching (using the public root key) than for signing.

Improve this question
7
  • Double hashing should be the minimum good to generate wallets.
    – John T
    Commented Jan 4, 2014 at 21:53
  • 1
    Except that now I know you've double hashed, all I have to do is double hash every phrase in my book and compare the result, which will always be the same. It's not the hash that is the security - don't confuse these two issues.
    – T9b
    Commented Jan 7, 2014 at 14:27
  • @T9b In fact a the hash can provide the security. In this case, a hash method that is so resource-intensive that brute-forcing would be infeasible would profile the perfect security. An example is the AES 256 CBC encryption method, which is proven to be secure against brute-forcing because of the computational complexity.
    – Steven Roose
    Commented Jan 7, 2014 at 16:26
  • Not everything is in the same way subject to a brute-force attack. F.e. Bitcoin addresses could also be brute-forced, but we don't see that as a threat either because it is not feasible for someone to try to brute-force it.
    – Steven Roose
    Commented Jan 7, 2014 at 16:28
  • 1
    I think you have completely misunderstood the scope of "brute-force" attacks. You are limiting your understanding to "trying to reverse a hash" which is, of course, very difficult. However bitcoin addresses are being compromised all the time, by people who assume that the hash is providing the security on a passphrase. The best example of this is brain wallets, which are being compromised all the time by brute-force attacks using a dictionary of possible phrases. The hash doesn't make them secure.
    – T9b
    Commented Jan 8, 2014 at 12:26

3 Answers 3

Reset to default
1

Yes, BIP39 is one such way.

Electrum has a different, mutually incompatible way.

Improve this answer
2
  • This is not true. Mnemonic Codes work the other way around, where the passphrase is generated from the key. Of you would want to use BIP39 to generate a key from a passphrase, your passphrase can only contain a fixed number of words from the predefined word list.
    – Steven Roose
    Commented Apr 28, 2015 at 18:22
  • @StevenRoose It's more of a way to convert between passphrase and key at will. And, as far as security goes, Electrum uses a predefined wordlist too :). Electrum does have the nice property that people can use a wordlist in their native language, though.
    – Nick ODell
    Commented Apr 28, 2015 at 18:38
-1

Actually it's not the form of the private key that is important, it is the fact that the public key is derived from the private key.

Technically speaking the private key can be anything as long as the public key can be used to confirm that your private key was used to sign the transaction (or any other thing like a contract or a message). This is the purpose of the public key.

The way in which the public key is created from the private key is standardised, and that's all that matters from a bitcoin cryptography point of view.

From a security point of view, however, you need to be careful about how you decide your private key.

Starting with a private key that is easily crackable, like a song lyric or common phrase in any language is very dangerous. It can be cracked by simply from a rainbow table. Now imagine that you take that same rainbow table and hash every value, and then create public keys for each of your hashes... you still get the same result - very easy to discover the private key.

There are ways to improve this security of this...

Improve this answer
2
  • Besides that this does not answer my question, your point against the idea is not quite valid. The reason to implement a standard is two-fold, it can also help to ensure security. The key to ensuring secure passphrase-to-private-key translation is the way the private key is calculated. A weak method like a single SHA-256 hash is indeed very insecure. But there are ways to change this. As an example, take the routine of X rounds of SHA-256 and Y rounds of Scrypt in which X and Y are chosen so that key calculation takes around 3 seconds on a standard machine. Quite brute-force resistent, no?
    – Steven Roose
    Commented Jan 6, 2014 at 16:38
  • I would say that standardising this gives an attacker knowledge on how far they have to go. If I had a simple passphrase and it was known that it was hashed n times, to create the private key, an attacker would know exactly what they would need to do to test their database of possible passphrases. In other words it doesn't matter how many times or what types of hash algo was used, if you know this info the private key is findable. To improve this you must add something that is only known at the time of creation or some other random element.
    – T9b
    Commented Jan 7, 2014 at 14:19
-1

There is a way to take a password/passphrase and turn it into a BIP39 mnemonic:

  1. Create a hash of your password/passphrase, output in hexadecimal notation. You can do this using any number of tools, both online and offline. You are not strictly limited to SHA.

  2. Go to the BIP39 generator created by Ian Coleman. Select the radio button which reveals entropy details.

  3. Copy/paste your hexadecimal hash output into the entropy box.

  4. Select the dropdown menu item for Mnemonic length. 12 is the most common seed format.

The generator will now output a 12-word BIP39 mnemonic, which can be used to seed a wallet.

"I want to be able to switch between wallet apps just taking my master key with me."

That can be done easily enough by copying your seed words over to the alternate wallets. A passphrase is not necessary. The reason you might want to create your own password/passphrase-based seed is that you want to be able to regenerate your seed from scratch should you misplace or delete your seed words. Ordinarily, if you lose your seed words, you lose the ability to recreate the HD wallet. If your seed words were generated from a password/passphrase (brainwallet-style), then recreating your seed words is trivial, assuming you have access to a BIP39 generator and a hashing utility.

Improve this answer
2
  • Assuming you have access to that specific arbitrary piece of software. This is a genuinely bad thing for anybody to be doing and will result in loss of funds in some cases.
    – Claris
    Commented Jan 23, 2019 at 12:02
  • "Assuming you have access to that specific arbitrary piece of software." -- It doesn't have to be any particular piece of software. If you have the skill and know-how, you could code them yourself. "This is a genuinely bad thing for anybody to be doing" -- If you do not take proper precautions and you generate poor passwords/passphrases, then you have no business generating brainwallet keys. I agree. That said, there is nothing in my answer which is incorrect. You can create a valid BIP39 mnemonic seed from a brainwallet-style password/passphrase. Caveats apply.
    – John C.
    Commented Jan 23, 2019 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.