I have memorized a very long and secure passphrase, that when hashed with sha256, I can use the result as an ECDSA private key, and use it as a brain-address for Bitcoin.

Now I need more bitcoin addresses, and instead of memorizing a new long and secure passphrase, I am thinking about just hashing the previous hash, over and over again to create new keys.

So I can build a simple software to which I type the passphrase and I tell him I want the key of the address number 58, so it just has to sha256 the passphrase 58 times to get that key.

If the greatest hacker ever had for example the first 500 bitcoin addresses that were generated with my passphrase, and if that hacker knew how those private keys where generated, would he have any chance to hack this system?

I am pretty sure he wouldn't but I want to make sure, because this is for a project at my job.


This approach will work, but there's another approach I want you to suggest.

As for why it's secure (or better the ways to attack):

  • Break the elliptic curve discrete logarithm problem. If you can do this you can just grab the first address out of your addresses, solve for the private key and derive all subsequent ones. This is generally considered infeasible.
  • Brute-force your passphrase. This is impossible as you describe it as "very long and secure".

Now for the alternative approach:

Don't use iterated hashing on your password for the ECDSA key derival. Use HKDF-extract on your password and then derive each indexed key using HKDF-expand which will allow you to supply context-information. You could simply use "1", "2","3",... as context info here. Use the derived values as ECDSA private keys.

The advantages are:

  • Independent keys. Compromise of one private key doesn't imply compromise of all subsequent private keys, because they are all independent.
  • Higher speed. If you only want to access your account number 500, you'd have to iterate your hash function 500 times (which may take a moment). With HKDF you get this at a few HMAC calls independently of the index.
  • More security. If you use HKDF you don't need to store / buffer 499 intermediate private keys on your machine, whereas with iterated hashing you'd have to (although you still have to store the master password).
| improve this answer | |
  • $\begingroup$ There may another fancy attack that I may have missed (unlikely I think), so maybe wait a couple of days to see if someone else comes up with an attack. The other points still apply. $\endgroup$ – SEJPM Nov 2 '15 at 22:12
  • $\begingroup$ Hey thanks very much for your answer, will definitely try that. I will do as you said, and if no one replies with a possible hack on this, i will use it. But I would like to point out something: Now that I think deeply about it, I realiced there is a much better way to do what i firstly proposed: to generate the 500th private key, you just hash the master key with the number 500 concatenated to it. That way, if a hacker gets any private key other than the master, he wont be able to get more. Would that work just as good as the HKDF-extract ? $\endgroup$ – Nathan Parker Nov 2 '15 at 23:00
  • 2
    $\begingroup$ @Nathan Parker You might find my answer here helpful; in particular the last sentence, where I mention some reasons to prefer HKDF over H(key || info) $\endgroup$ – Tim McLean Nov 3 '15 at 0:00
  • $\begingroup$ I will use HKDF then. Thank you very much both of you, really helped. $\endgroup$ – Nathan Parker Nov 3 '15 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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