<p>You merely took a look at what a single entity this website talks about said in a very generic way. There are others which for 256 bit just say for example "> 2030" without stating an upper bound. That's because it isn't known.</p>

<p>You can't simply say that ECDSA with n bit is secure and ECDSA with n-1 bit isn't. There is a lot to be taken into account, like the elliptic curve being used, or the incentive and the resources of an attacker.</p>

<p><a href="https://i.sstatic.net/pH9sQ.jpg" rel="nofollow noreferrer">One can't simply brute-force their way to a 256 bit key</a>. One has to find a vulnerability a smart way. As long as this doesn't happen, bitcoin is secure. And no one can predict whether, let alone when this will happen (if it will happen) until it is proven to be feasible or proven to be infeasible.</p>

CC BY-SA 3.0
2016-08-25T16:08:19.927Z
Nice picture, but unfortunately, forging an ECDSA signature for a 256-bit curve only requires around 2^128 EC group operations... equivalent to counting to ~2^140, not 2^256. Still infeasibly much (right now), but many orders of magnitude less than what is claimed there.
Pieter Wuille
CC BY-SA 3.0
2016-08-25T16:44:21.283Z
Thanks for your response, I know that the elliptic curve being used, incentive, and the resources of an attacker are important factors. However, in the bitcoin sample incentive and the resources of the attacker could be very large!
Tail of Godzilla
CC BY-SA 3.0
2016-08-25T15:16:51.260Z
2016-08-25T15:16:51.260Z
UTF-8
<p>Bitcoin uses the secp256k1 elliptic curve with 256 bit private/public key pair cryptography to render ECDSA functionality. The two bitcoin explorer (bx) commands below replicate statements/results in the site references above. Note the private key is a 256-bit hexadecimal encoded number.</p>

<p><code>% echo "e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262" | bx base58check-encode -v 128</code></p>

<p><strong>5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF</strong> - is the associated uncompressed private key that is encoded using base58 check, also called Wallet Input Format (WIF).</p>

<p><code>% echo "e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262" | bx ec-to-public -u | bx ec-to-address -v 0</code></p>

<p><strong>1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj</strong> - is the address corresponding to the associated uncompressed public key.</p>

<p>If I were a hacker that wanted to compromise secp256k1, I would first compromise the <a href="http://www.bitcoinrichlist.com/top100" rel="noreferrer">top 100 rich list wallets</a> that are not using multisig first.  Bitcoin is the most excellent canary in the cryptographic coal mine to determine when secp256k1 fails. The banking system would never be such a good crypto-Samaritan. </p>

<p>From <a href="http://www.secg.org/sec2-v2.pdf" rel="noreferrer">Table 1</a> the elliptic curve subject matters experts assert the strength of a 256-bit secp256k1 private key has the strength of 128 bits of encryption when the associated public key is exposed.  To brute force attack a public key to obtain a public key with 128 bits of entropy will cost at least $100M in electricity at 5 cents per KW-Hr using almost perfectly efficient quantum computers. It is mostly supposition to arrive at projections for when an mathematical back doors for compromising secp256k1. </p>

<p>You can read about <a href="https://en.wikipedia.org/wiki/Elliptic_curve_cryptography" rel="noreferrer">Shor's algorythm</a>.  The Bitcoin Community is very shrewd concerning planning for <a href="http://www.bitcoinnotbombs.com/bitcoin-vs-the-nsas-quantum-computer/" rel="noreferrer">quantum computing attacks</a>. Also, the NSA issued some interesting warnings concerning Suite B technology a few months back, but those pages are no longer publicly visible. </p>

<p>No telling what path the Bitcoin community will take, but I assure you the hardfork will be much faster than trying to double Bitcoin's maximum blocksize.</p>

CC BY-SA 3.0
2017-08-09T06:30:46.717Z
If the minimum it would cost to brute force is $100M, we may be approaching the point of relevancy. The largest Satoshi wallet now contains $422M of bitcoins.
Eli
CC BY-SA 3.0
2016-08-27T01:31:05.233Z
2016-08-27T01:31:05.233Z
skaht
<p>I read <a href="https://en.bitcoin.it/wiki/Private_key" rel="noreferrer">here</a>:</p>

<blockquote>
  <p>In Bitcoin, a private key is usually a 256-bit number ...</p>
</blockquote>

<p>Although it is a silly question, is this length safe? </p>

<p>Based on this <a href="https://www.keylength.com/en/3/" rel="noreferrer">site</a>, Elliptic Curve 256 bit keys are safe until 2040. Does Bitcoin network change its key size in that far future?? If Bitcoin reaches 2040, what happens to many wallets that use 256 bit keys?</p>

<security><private-key>
The length of the Bitcoin's private keys
Tail of Godzilla
# The length of the Bitcoin's private keys

(Asked by: username_0 on 2016-08-25)

I read [here](https://en.bitcoin.it/wiki/Private_key):

> In Bitcoin, a private key is usually a 256-bit number ...

Although it is a silly question, is this length safe?

Based on this [site](https://www.keylength.com/en/3/), Elliptic Curve 256 bit keys are safe until 2040. Does Bitcoin network change its key size in that far future?? If Bitcoin reaches 2040, what happens to many wallets that use 256 bit keys?

**Tags:** security, private-key


---

## 2 answers

### Answer by username_3 on 2016-08-27. Score: 14 | Accepted answer

Bitcoin uses the secp256k1 elliptic curve with 256 bit private/public key pair cryptography to render ECDSA functionality. The two bitcoin explorer (bx) commands below replicate statements/results in the site references above. Note the private key is a 256-bit hexadecimal encoded number.

`% echo "e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262" | bx base58check-encode -v 128`

**5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF** - is the associated uncompressed private key that is encoded using base58 check, also called Wallet Input Format (WIF).

`% echo "e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262" | bx ec-to-public -u | bx ec-to-address -v 0`

**1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj** - is the address corresponding to the associated uncompressed public key.

If I were a hacker that wanted to compromise secp256k1, I would first compromise the [top 100 rich list wallets](http://www.bitcoinrichlist.com/top100) that are not using multisig first. Bitcoin is the most excellent canary in the cryptographic coal mine to determine when secp256k1 fails. The banking system would never be such a good crypto-Samaritan.

From [Table 1](http://www.secg.org/sec2-v2.pdf) the elliptic curve subject matters experts assert the strength of a 256-bit secp256k1 private key has the strength of 128 bits of encryption when the associated public key is exposed. To brute force attack a public key to obtain a public key with 128 bits of entropy will cost at least $100M in electricity at 5 cents per KW-Hr using almost perfectly efficient quantum computers. It is mostly supposition to arrive at projections for when an mathematical back doors for compromising secp256k1.

You can read about [Shor's algorythm](https://en.wikipedia.org/wiki/Elliptic_curve_cryptography). The Bitcoin Community is very shrewd concerning planning for [quantum computing attacks](http://www.bitcoinnotbombs.com/bitcoin-vs-the-nsas-quantum-computer/). Also, the NSA issued some interesting warnings concerning Suite B technology a few months back, but those pages are no longer publicly visible.

No telling what path the Bitcoin community will take, but I assure you the hardfork will be much faster than trying to double Bitcoin's maximum blocksize.

> **Comments:**
> **username_4**: If the minimum it would cost to brute force is $100M, we may be approaching the point of relevancy. The largest Satoshi wallet now contains $422M of bitcoins.  

---

### Answer by username_1 on 2016-08-25. Score: 1

You merely took a look at what a single entity this website talks about said in a very generic way. There are others which for 256 bit just say for example "> 2030" without stating an upper bound. That's because it isn't known.

You can't simply say that ECDSA with n bit is secure and ECDSA with n-1 bit isn't. There is a lot to be taken into account, like the elliptic curve being used, or the incentive and the resources of an attacker.

[One can't simply brute-force their way to a 256 bit key](https://i.sstatic.net/pH9sQ.jpg). One has to find a vulnerability a smart way. As long as this doesn't happen, bitcoin is secure. And no one can predict whether, let alone when this will happen (if it will happen) until it is proven to be feasible or proven to be infeasible.

> **Comments:**
> **username_2**: Nice picture, but unfortunately, forging an ECDSA signature for a 256-bit curve only requires around 2^128 EC group operations... equivalent to counting to ~2^140, not 2^256. Still infeasibly much (right now), but many orders of magnitude less than what is claimed there.  
> **username_0**: Thanks for your response, I know that the elliptic curve being used, incentive, and the resources of an attacker are important factors. However, in the bitcoin sample incentive and the resources of the attacker could be very large!  

---

