Topic: private key generation always in 256bit range or even lower ? (Read 152 times)
The key size always depends on the security requirements. In general, a 256-bit key size is considered to be very strong and provides good security. However, if higher security is required, then a larger key size should be used.
I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets?
Bitcoin private keys have exactly 256 bits. A private key with fewer would require that the remaining bits be set to something.
From a security perspective, there would be nothing inferior about the keys that are closer to 1, and nothing superior about the keys that are closer to 10.
I am not entirely sure that this is true. One might think that the keys from the lower range tend to be found much sooner than their counterparts further up. With the simple reason that most cracking tools and their developers naturally start counting at one and increment linearly. Only a small exception would come up with the idea to start counting at eg 30% of a range, or to start counting backwards, or randomly. As for the rest, I'm with you.Thus, most brute force attempts checking a range start at 1, making the low end of the 256-bit range more vulnerable simply because it is the range checked most often.
On the other hand, since there are so many people already checking the low end, an attacker might want to choose a different range that does not have as much attention in order to avoid the competition.
In the end, a randomly generated private key is extremely unlikely to be in a range that any attacker is searching, so there is no practical reason to be concerned.
From a security perspective, there would be nothing inferior about the keys that are closer to 1, and nothing superior about the keys that are closer to 10.
I am not entirely sure that this is true. One might think that the keys from the lower range tend to be found much sooner than their counterparts further up. With the simple reason that most cracking tools and their developers naturally start counting at one and increment linearly. Only a small exception would come up with the idea to start counting at eg 30% of a range, or to start counting backwards, or randomly. As for the rest, I'm with you.
From a security perspective, there would be nothing inferior about the keys that are closer to 1, and nothing superior about the keys that are closer to 10.
I am not entirely sure that this is true. One might think that the keys from the lower range tend to be found much sooner than their counterparts further up. With the simple reason that most cracking tools and their developers naturally start counting at one and increment linearly. Only a small exception would come up with the idea to start counting at eg 30% of a range, or to start counting backwards, or randomly. As for the rest, I'm with you. 
Sometimes the best way to understand something is to make a scaled-down version of it. Imagine a toy cryptocurrency where private keys were between 1 and 10. As long as the process that chooses your private key is unbiased, then each one is as likely to come up as another. From a security perspective, there would be nothing inferior about the keys that are closer to 1, and nothing superior about the keys that are closer to 10.
Actually, I like that idea. Toy bitcoins that make the protocol look really simple. A whole set could be built around it like LEGO. And not just protocol sets, there could also be policy (how the rest of the world interacts with bitcoin) sets as well.
Maybe even make a Monopoly clone but with a decentralization theme instead of running to the bank.
[...] I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets? I would simply expect that the highest possible number of bits would always be used but do the common software/hardware wallets really do that? [...]
Sometimes the best way to understand something is to make a scaled-down version of it. Imagine a toy cryptocurrency where private keys were between 1 and 10. As long as the process that chooses your private key is unbiased, then each one is as likely to come up as another. From a security perspective, there would be nothing inferior about the keys that are closer to 1, and nothing superior about the keys that are closer to 10. 
Keys are normally padded when they're generates so they'll all be 256 bit keys but some can be smaller. A quick calculation says the first 32 bits will be 0 every 4.3 billion keys (232).
Wallets that use nmemonics ONLY use 256 bit seeds (the number used to generate private keys) when there are 24 words in the phrase. 12 word nmemonics are a representation of 128 bit seeds. A lot of wallets use 24 words now but there's still enough that use 12, electrum used to vary its length too between ~10-15 word nmemonics which did add a lot more variance than just 128 bits but was probably considered redundant by them as it was removed iirc (not sure if it's been reinstated yet). Regardless the size of the seed used, a hashing operation derives all of the keys so they're still 256 bit.
Wallets that use nmemonics ONLY use 256 bit seeds (the number used to generate private keys) when there are 24 words in the phrase. 12 word nmemonics are a representation of 128 bit seeds. A lot of wallets use 24 words now but there's still enough that use 12, electrum used to vary its length too between ~10-15 word nmemonics which did add a lot more variance than just 128 bits but was probably considered redundant by them as it was removed iirc (not sure if it's been reinstated yet). Regardless the size of the seed used, a hashing operation derives all of the keys so they're still 256 bit.
I am aware that there are various wallet tools out there in the world and probably no one will know the exact behavior of each one by heart. But maybe you can answer the following question in general...
I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets? I would simply expect that the highest possible number of bits would always be used but do the common software/hardware wallets really do that?
Looking forward to your answers.
I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets? I would simply expect that the highest possible number of bits would always be used but do the common software/hardware wallets really do that?
Looking forward to your answers.
Statistically speaking, it is so rare for a wallet to generate keys with that many leading zeros that it can be considered an impossibility.
But provided that software gets 32 random bytes for each generation, then yes, it can be considered fully secure.
Because randomness comes in the form of bytes & dwords, it is very rare to see a list of random bits that is not divisive by 8, 16, 32, and so on.
I am aware that there are various wallet tools out there in the world and probably no one will know the exact behavior of each one by heart. But maybe you can answer the following question in general...
I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets? I would simply expect that the highest possible number of bits would always be used but do the common software/hardware wallets really do that?
Looking forward to your answers.
I wonder if wallet tools fundamentally and exclusively generate private keys in the 256 bit range. Or can it happen that such a tool generates a 103bit or 87bit private key when generating addresses/wallets? I would simply expect that the highest possible number of bits would always be used but do the common software/hardware wallets really do that?
Looking forward to your answers.
Jump to: