<p>While the question isn't an exact duplicate, the answer essentially is, so I'm going to quote <a href="https://bitcoin.stackexchange.com/a/1715/22">this answer</a> by <a href="https://bitcoin.stackexchange.com/users/208/pieter-wuille">Pieter Wuille</a>:</p>

<blockquote>
  <p>As is normal when doing Elliptic Curve encryption, a private key is
  simply a random number. In the case of secp256k1, the elliptic curve
  used by Bitcoin, it has to be a number between 1 and
  115792089210356248762697446949407573529996955224135760342422259061068512044368
  (or in hexadecimal, between 1 and
  FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551.</p>
  
  <p>This private key is converted to a public key by performing an EC
  point multiplication with the curve's base point. The result is an
  (x,y) coordinate pair, which constitutes the public key.</p>
  
  <p>Finally, RIPEMD160(SHA256(pubkey)), where pubkey is a serialization of
  those coordinates, is computed, and encoded in base58, together with a
  checksum. This becomes the address.</p>
</blockquote>

<p>So the short answer is yes, as long as the resulting hash is less than or equal to FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 any SHA256 hash is an acceptable privkey.</p>

<p>As for a canonical method of mapping a passphrase to a privkey, I don't believe there is one - after all, this functionality isn't built into the Satoshi client (at least not yet) so there cannot, by definition, be a canonical method. The closest thing I can think of would be the <a href="https://en.bitcoin.it/wiki/Mini_private_key_format" rel="nofollow noreferrer">mini private key format</a> used by Casascius physical bitcoins, which could easily be used with a passphrase instead. Indeed Casascius' <a href="https://github.com/casascius/Bitcoin-Address-Utility" rel="nofollow noreferrer">Bitcoin Address Utility</a> is often the app of choice for those wishing to make "mental wallets" from memorized passphrases rather than random inputs.</p>

CC BY-SA 3.0
2012-05-09T16:42:07.130Z
Thank you very much for your answer! AFAICS, Casascius doesn't seem to care at all about the fact that the result of SHA256 might not result in a valid private key. I understand now that this is a very rare corner case (about 2*10^-10), but still. Maybe hashing a second time in case the first result is larger would be a sensible behavior?
Noah
CC BY-SA 3.0
2012-05-09T17:57:14.037Z
@Noah If Casascius would not obtain a valid private key, how do you think he would be able to obtain the public key from it? Without a valid private key you can't have any Bitcoin Address to put the coins to, and as far as I know, every Physical Bitcoin clearly shows what address is stored in it.
ThePiachu
CC BY-SA 3.0
2012-05-09T18:37:21.320Z
You're right of course, but since my question was specifically aiming at these corner cases, I think pointing out that they are simply not handled at all in the "app of choice" for brain wallets is justified. Besides, there might be automated implementations of such a mapping which cannot afford to just ignore these cases. Anyway, criticizing the Bitcoin Address Utility was in no way my intention, but obviously it does not cover the case I was asking for.
Noah
CC BY-SA 3.0
2012-05-09T20:37:07.760Z
I can't say without looking over the code whether this corner case is handled at all, letalone how it is handled, but I would assume that in the extremely unlikely event of sha256(passcode) producing an invalid privkey the BouncyCastle crypto library would throw an error rather than generating an invalid keypair.
David Perry
CC BY-SA 3.0
2012-05-09T20:39:02.743Z
The most common way it's handled is to reduce modulo the generator. I believe the OpenSSL libraries do this automatically. (The consensus among the security community is that reducing modulo the generator has no significant effect on the security properties and there's no benefit to using more sophisticated methods.)
David Schwartz
CC BY-SA 3.0
2012-05-09T15:29:01.127Z
2012-05-09T15:29:01.127Z
2017-04-13T12:47:36.707Z
David Perry
<p>Is it possible to map a pass-phrase directly to a Bitcoin private key by using its SHA256 hash? I remember reading somewhere that not all 256 bit values are valid ECDSA private keys. If so, how can I make sure that the resulting hash is valid, or is there some other canonical way of mapping a pass-phrase to a private key?</p>

<hash><private-key><sha256><passphrase>
Can an SHA256 hash be used as an ECDSA private key?
Noah
# Can an SHA256 hash be used as an ECDSA private key?

(Asked by: username_0 on 2012-05-09)

Is it possible to map a pass-phrase directly to a Bitcoin private key by using its SHA256 hash? I remember reading somewhere that not all 256 bit values are valid ECDSA private keys. If so, how can I make sure that the resulting hash is valid, or is there some other canonical way of mapping a pass-phrase to a private key?

**Tags:** hash, private-key, sha256, passphrase


---

## 1 answers

### Answer by username_1 on 2012-05-09. Score: 4 | Accepted answer

While the question isn't an exact duplicate, the answer essentially is, so I'm going to quote [this answer](https://bitcoin.stackexchange.com/a/1715/22) by [Pieter Wuille](https://bitcoin.stackexchange.com/users/208/pieter-wuille):

> As is normal when doing Elliptic Curve encryption, a private key is
> simply a random number. In the case of secp256k1, the elliptic curve
> used by Bitcoin, it has to be a number between 1 and
> 115792089210356248762697446949407573529996955224135760342422259061068512044368
> (or in hexadecimal, between 1 and
> FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551.
>
> This private key is converted to a public key by performing an EC
> point multiplication with the curve's base point. The result is an
> (x,y) coordinate pair, which constitutes the public key.
>
> Finally, RIPEMD160(SHA256(pubkey)), where pubkey is a serialization of
> those coordinates, is computed, and encoded in base58, together with a
> checksum. This becomes the address.

So the short answer is yes, as long as the resulting hash is less than or equal to FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 any SHA256 hash is an acceptable privkey.

As for a canonical method of mapping a passphrase to a privkey, I don't believe there is one - after all, this functionality isn't built into the Satoshi client (at least not yet) so there cannot, by definition, be a canonical method. The closest thing I can think of would be the [mini private key format](https://en.bitcoin.it/wiki/Mini_private_key_format) used by Casascius physical bitcoins, which could easily be used with a passphrase instead. Indeed Casascius' [Bitcoin Address Utility](https://github.com/casascius/Bitcoin-Address-Utility) is often the app of choice for those wishing to make "mental wallets" from memorized passphrases rather than random inputs.

> **Comments:**
> **username_0**: Thank you very much for your answer! AFAICS, Casascius doesn't seem to care at all about the fact that the result of SHA256 might not result in a valid private key. I understand now that this is a very rare corner case (about 2*10^-10), but still. Maybe hashing a second time in case the first result is larger would be a sensible behavior?  
> **username_2**: @username_0 If Casascius would not obtain a valid private key, how do you think he would be able to obtain the public key from it? Without a valid private key you can't have any Bitcoin Address to put the coins to, and as far as I know, every Physical Bitcoin clearly shows what address is stored in it.  
> **username_0**: You're right of course, but since my question was specifically aiming at these corner cases, I think pointing out that they are simply not handled at all in the "app of choice" for brain wallets is justified. Besides, there might be automated implementations of such a mapping which cannot afford to just ignore these cases. Anyway, criticizing the Bitcoin Address Utility was in no way my intention, but obviously it does not cover the case I was asking for.  
> **username_1**: I can't say without looking over the code whether this corner case is handled at all, letalone how it is handled, but I would assume that in the extremely unlikely event of sha256(passcode) producing an invalid privkey the BouncyCastle crypto library would throw an error rather than generating an invalid keypair.  
> **username_3**: The most common way it's handled is to reduce modulo the generator. I believe the OpenSSL libraries do this automatically. (The consensus among the security community is that reducing modulo the generator has no significant effect on the security properties and there's no benefit to using more sophisticated methods.)  

---

