<p>The only way to determine the private key associated with a given public key is by a brute force method, spanning the entire 2^256 key space. More specifically, any number from 0x1 to 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (order of G) is a valid private key.</p>

<p>According to an article on <a href="https://www.wikiwand.com/en/Brute-force_attack#/Theoretical_limits" rel="nofollow noreferrer">wikipedia</a> on brute force cryptography, it would take 50 supercomputers that could check 10^18 keys per second about 3x10^51 years to exhaust the 256 bit key space. However, this number fails to account for theoretical limits of energy consumption and computation from Landauer's principle. I decided to put in some work to show the theoretical limits.</p>

<blockquote>
  <p>Landauer's Principle</p>
</blockquote>

<p>Laundauer's principle basically provides us with the lower limit of energy consumption needed to flip a bit as a function of temperature (it is much more complex, but we can leave that aside for now.) That lower limit is given by the formula: kT * ln(2) (where k is the Boltzmann constant (1.38*10^-23) and T is temperature in Kelvin scale.) So, for a 2^256 key space, that energy is 2^256*kT*ln(2). The energy that I'm calculating below, is only to generate keys in the 2^256 key space, and does not involve the energy to generate public keys from them and check the result. </p>

<p>Since I'm in Mumbai, I will take the liberty to use temperature of 25 degree celsius or 298 Kelvin. Using the above formula, E = 2^256*kT*ln(2), we get energy as 3.3x10^56. According to <a href="https://yearbook.enerdata.net/electricity/electricity-domestic-consumption-data.html" rel="nofollow noreferrer">this</a> article, the global electricity consumption was 21,700 TWh in 2017. That's equivalent to 7.8*10^19 Joules. So, even assuming that world's entire electricity supply is diverted to generation of the keys in 256-bit key space, we would still need electricity that is 5*10^36 times more than that is generated today.</p>

CC BY-SA 4.0
2019-03-21T15:14:28.480Z
There are better (known) ways than brute force to determine the private key using [for example](https://en.wikipedia.org/wiki/Discrete_logarithm#Properties) Baby-step giant-step or Pollard's rho algorithm. Both have running time in `O(sqrt(n))` where in our case `n` is close to `2^256`.
nickler
CC BY-SA 4.0
2019-03-21T19:16:07.187Z
@nickler That's why we use 256-bit keys with elliptic curve algorithms even though 128 bits is sufficient for AES keys. The public key does leak some information about the private key, and we need the private key to still have enough hidden information left over after that to be secure.
David Schwartz
CC BY-SA 4.0
2019-03-21T23:20:41.383Z
@DavidSchwartz just out out curiosity, do you have any sources talking about how the public key leaks information? I would be quite interested in reading that :)
Matt
CC BY-SA 4.0
2019-03-22T00:31:58.293Z
@Matt See either [Big Step / Little Step](https://en.wikipedia.org/wiki/Baby-step_giant-step) or [Pollard's Rho](https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm) for details. A simple way to get the general idea is that if you guess at the private key and the public key that results is not close to the actual public key, your guess at the private key cannot be close to the real private key. So you don't have to try every possible private key.
David Schwartz
CC BY-SA 4.0
2019-03-21T10:07:20.130Z
2019-03-21T10:07:20.130Z
Ugam Kamat
<p>Hi I was just looking for some information on how long it would take to crack a private key in bitcoin using a brute force approach and I couldn't find a very good answer for how long it takes to check whether one specific key (or every key) would work.</p>

<p>So essentially what I am asking is how long would the elliptic curve multiplication process take to check whether a single private key would work for a given public key (on average), thanks :)</p>

<cryptography>
What is the current computing speed of performing an elliptic curve multiplication?
Matt
# What is the current computing speed of performing an elliptic curve multiplication?

(Asked by: username_0 on 2019-03-20)

Hi I was just looking for some information on how long it would take to crack a private key in bitcoin using a brute force approach and I couldn't find a very good answer for how long it takes to check whether one specific key (or every key) would work.

So essentially what I am asking is how long would the elliptic curve multiplication process take to check whether a single private key would work for a given public key (on average), thanks :)

**Tags:** cryptography


---

## 1 answers

### Answer by username_1 on 2019-03-21. Score: 1 | Accepted answer

The only way to determine the private key associated with a given public key is by a brute force method, spanning the entire 2^256 key space. More specifically, any number from 0x1 to 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (order of G) is a valid private key.

According to an article on [wikipedia](https://www.wikiwand.com/en/Brute-force_attack#/Theoretical_limits) on brute force cryptography, it would take 50 supercomputers that could check 10^18 keys per second about 3x10^51 years to exhaust the 256 bit key space. However, this number fails to account for theoretical limits of energy consumption and computation from Landauer's principle. I decided to put in some work to show the theoretical limits.

> Landauer's Principle

Laundauer's principle basically provides us with the lower limit of energy consumption needed to flip a bit as a function of temperature (it is much more complex, but we can leave that aside for now.) That lower limit is given by the formula: kT \* ln(2) (where k is the Boltzmann constant (1.38\*10^-23) and T is temperature in Kelvin scale.) So, for a 2^256 key space, that energy is 2^256\*kT\*ln(2). The energy that I'm calculating below, is only to generate keys in the 2^256 key space, and does not involve the energy to generate public keys from them and check the result.

Since I'm in Mumbai, I will take the liberty to use temperature of 25 degree celsius or 298 Kelvin. Using the above formula, E = 2^256\*kT\*ln(2), we get energy as 3.3x10^56. According to [this](https://yearbook.enerdata.net/electricity/electricity-domestic-consumption-data.html) article, the global electricity consumption was 21,700 TWh in 2017. That's equivalent to 7.8\*10^19 Joules. So, even assuming that world's entire electricity supply is diverted to generation of the keys in 256-bit key space, we would still need electricity that is 5\*10^36 times more than that is generated today.

> **Comments:**
> **username_2**: There are better (known) ways than brute force to determine the private key using [for example](https://en.wikipedia.org/wiki/Discrete_logarithm#Properties) Baby-step giant-step or Pollard's rho algorithm. Both have running time in `O(sqrt(n))` where in our case `n` is close to `2^256`.  
> **username_3**: @username_2 That's why we use 256-bit keys with elliptic curve algorithms even though 128 bits is sufficient for AES keys. The public key does leak some information about the private key, and we need the private key to still have enough hidden information left over after that to be secure.  
> **username_0**: @username_3 just out out curiosity, do you have any sources talking about how the public key leaks information? I would be quite interested in reading that :)  
> **username_3**: @username_0 See either [Big Step / Little Step](https://en.wikipedia.org/wiki/Baby-step_giant-step) or [Pollard's Rho](https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm) for details. A simple way to get the general idea is that if you guess at the private key and the public key that results is not close to the actual public key, your guess at the private key cannot be close to the real private key. So you don't have to try every possible private key.  

---

