<p>Yes you could start creating a database of private/public keys but that wouldn’t get you anywhere, there is not enough storage in the world to ever store any significant portion of the key space.</p>
<p>To get a sense of the numbers we are talking about, the approximated number of protons in the universe is 10^80. Even if each row in the database can be stored in a proton (it can’t, it takes 256 bits) and all matter in the universe was repurposed for your database there would still not be enough space.</p>
<p>Not to mention the computation work required to calculate all the public keys.</p>

CC BY-SA 4.0
2022-05-15T16:12:27.160Z
Thanks Mike, yes I realise it's an unimaginably huge number and obviously impossible to ever hope to store any meaningful % of the total number of possible keys, but I'm still curious about the lowest numbers - say if someone just happened to end up with a private key of 10, isn't it feasible that the public key for this would be easily recognisable because it's likely that several people will have experimented with inputting such a low number into online public key generators just to see what comes out
b0d
CC BY-SA 4.0
2022-05-15T17:35:43.037Z
yes low entropy keys will be precalculated and your money will be snatched immediately, this includes brainwallet keys but if you use a proper RNG you have nothing to worry about.
Mike D
CC BY-SA 4.0
2022-05-15T17:40:35.880Z
In fact you can see that any coins sent to the address associated with the key 10 are instantly snatched https://www.blockchain.com/btc/address/1GDWJm5dPj6JTxF68WEVhicAS4gS3pvjo7
Mike D
CC BY-SA 4.0
2022-05-16T03:54:06.713Z
One more question then - do most wallet providers include a mechanism in their code to prevent very low-numerated keys from being generated?
b0d
CC BY-SA 4.0
2022-05-16T12:53:53.197Z
No because the odds of this happening by chance is practically zero, you would have to do it on purpose
Mike D
CC BY-SA 4.0
2022-05-17T12:25:18.060Z
And worse, actively avoiding low numbers (or ajy set with specific rare properties) would in fact help attackers: they'd know they can skip searching those when brute forcing. The way to make things hardest for attackers is by making sure every valid private key is equally likely.
Pieter Wuille
CC BY-SA 4.0
2022-05-15T13:21:31.987Z
2022-05-15T13:21:31.987Z
Mike D
<p>If an EC private key k is very small, say &quot;1&quot;, is it feasible to calculate the private key k from its public key K, since there would only be one step back to generator point G and therefore the discrete logarithm would only need to be found once to land on G?</p>
<p>Even if this is not feasible without brute force, is there anything preventing a database of private/public keys being built over time, starting at 1,2,3... etc, such that all very low-numbered private keys could easily be revealed.</p>
<p>For instance, for the first billions of possible values of k, their K is saved in a database. Any public K could then be checked against these values for a match and if there is a match the private k is instantly known. I know the probability is still infinitesimally small but also billions of times higher than randomly checking values of k (and would continue increasing over time)</p>

<security><private-key><public-key><ecdsa><secp256k1>
Is it feasible to calculate EC private key k from public key K for very low values of k?
b0d
# Is it feasible to calculate EC private key k from public key K for very low values of k?

(Asked by: username_0 on 2022-05-15)

If an EC private key k is very small, say "1", is it feasible to calculate the private key k from its public key K, since there would only be one step back to generator point G and therefore the discrete logarithm would only need to be found once to land on G?

Even if this is not feasible without brute force, is there anything preventing a database of private/public keys being built over time, starting at 1,2,3... etc, such that all very low-numbered private keys could easily be revealed.

For instance, for the first billions of possible values of k, their K is saved in a database. Any public K could then be checked against these values for a match and if there is a match the private k is instantly known. I know the probability is still infinitesimally small but also billions of times higher than randomly checking values of k (and would continue increasing over time)

**Tags:** security, private-key, public-key, ecdsa, secp256k1


---

## 1 answers

### Answer by username_1 on 2022-05-15. Score: 1

Yes you could start creating a database of private/public keys but that wouldn’t get you anywhere, there is not enough storage in the world to ever store any significant portion of the key space.

To get a sense of the numbers we are talking about, the approximated number of protons in the universe is 10^80. Even if each row in the database can be stored in a proton (it can’t, it takes 256 bits) and all matter in the universe was repurposed for your database there would still not be enough space.

Not to mention the computation work required to calculate all the public keys.

> **Comments:**
> **username_0**: Thanks username_1, yes I realise it's an unimaginably huge number and obviously impossible to ever hope to store any meaningful % of the total number of possible keys, but I'm still curious about the lowest numbers - say if someone just happened to end up with a private key of 10, isn't it feasible that the public key for this would be easily recognisable because it's likely that several people will have experimented with inputting such a low number into online public key generators just to see what comes out  
> **username_1**: yes low entropy keys will be precalculated and your money will be snatched immediately, this includes brainwallet keys but if you use a proper RNG you have nothing to worry about.  
> **username_1**: In fact you can see that any coins sent to the address associated with the key 10 are instantly snatched https://www.blockchain.com/btc/address/1GDWJm5dPj6JTxF68WEVhicAS4gS3pvjo7  
> **username_0**: One more question then - do most wallet providers include a mechanism in their code to prevent very low-numerated keys from being generated?  
> **username_1**: No because the odds of this happening by chance is practically zero, you would have to do it on purpose  
> **username_2**: And worse, actively avoiding low numbers (or ajy set with specific rare properties) would in fact help attackers: they'd know they can skip searching those when brute forcing. The way to make things hardest for attackers is by making sure every valid private key is equally likely.  

---

