Uh-oh:
Someone asked nullius a question about random numbers.https://assets.amuniversal.com/321a39e06d6401301d80001dd8b71c47* nullius loves random numbers.
That is flatly incorrect. A secp256k1 private key has slightly less than 256 bits of entropy. But that is irrelevant:
In haste to reply, I slightly misspoke. A private key is simply a 256-bit number—slightly restricted in its range, because not all 256-bit numbers correspond to valid
points on the secp256k1 curve. A 256-bit number picked randomly from the uniform distribution has a negligible (about 2
-128) probability of being an invalid key.
A
securely created private key effectively has slightly less than 256 bits of entropy.
Hi sir, since this post is about blockchain, asking something related to entropy might be off-topic. Nevertheless..
So, the private key in BTC has a maximum of 256 bits of entropy. No matter how complex the entropy I am putting in in the first place, it will end up producing me a root key with 256 bits(even if I was initially putting in HEX in 1000-bit entropy or 10000 bit). Because in the end, after SHA256, it becomes 256bits..
Your question consists of two distinct parts: The part about private keys, and the part about SHA256.
SHA256 is irrelevant to creating a Bitcoin private key, unless you yourself are choosing to feed something into SHA256 to create the key. I strongly advise that you should not devise your own scheme for creating private keys—not when dealing with real money—not unless or until you study cryptography.
Most user keys from competently written Bitcoin wallets are created according to
the BIP 32 HD (Hierarchical Deterministic) wallet standard. If you are writing your own wallet software, you should use that (and I recommend using a library that provides the appropriate functions—unless/until you learn more about the underlying primitives, and why BIP 32 puts them together the way it does).
If you feed some arbitrary input into SHA256, and use the output as a key, then you are using SHA256 as an
entropy extractor. To design such a system properly, you should understand the concept of
min-entropy (as distinct from Shannon entropy). I know that I am tossing out unfamiliar jargon thick and fast, but there is a reason for that: These are advanced concepts that must be understood if you want to do this securely, without shooting yourself in the foot; and there is no way to summarize such a deep technical subject in a few paragraphs of a casual forum post. I therefore provide the terms that you can look up in an appropriate reference work.
The approximate security level that many people attain when they try to roll their own private keys:https://imgs.xkcd.com/comics/random_number.pngSo, my question is:
Will there be two different input producing the same hash result? (hypothetically, a 200-bit input entropy produces the same hash result of 20000bit...)
Maybe that's a stupid question to ask..
No, it is not a stupid question. SHA256 is a surjection. It accepts vastly more possible inputs (
preimages) than the possible outputs (
images) it can produce. By the
Pigeonhole Principle, there are many possible preimages for each hash image.
If you can find two different preimages that produce the same SHA256 image (without specifying what the image is), that is called a
collision attack. One of the security requirements for a cryptographically secure hash function is that finding a collision must be computationally infeasible, to the expected security level. SHA256 is secure against collision attacks. (Other previously popular hash functions,
MD5 and
SHA1, have been broken with collision attacks, and even chosen-prefix collisions.)
(o_e_l_e_o correctly explained this more briefly but with additional details (thank you), as I was writing and gathering links/images.)
It is not a matter of what you “believe”; and it is not the true explanation. I provided the factually correct explanation above.
I knew you're nuts, but you're supposed to be trying to rebut me or something? Go ahead and spend what little Bitcoin you have in leverage and lose it.
No, I was helpfully informing you that you are wrong, and you have no idea what you are talking about. Now, I am also informing you that you are rude, stupid, and pitiably foolish to be arguing with me from a state of gross ignorance.
Thank you so much for the constant long-form replies. I think because of you guys, more people are starting to understand bitcoin and especially cryptography.
Yes, I am quite into this kind of topic, especially how one can generate entropy, how the whole BIP32 thing, and more.
I also did my little research so I don't shoot noobie questions.(at least not that noobie).
So, basically, I don't trust any software/hardware wallet that generates keys for me. At least, i have to look into their codes but at the end of the day, I still do not feel comfortable with them. So the way I do it is I take iancole HTML page, and I feed it with my entropy(not arbitrary entropy). meanwhile, I have the bip32 /bip39 python code alongside so that i can cross-check. When the xprvs turn out to be the same, i can be relief, I can go ahead funding it at least nothing can go too wrong from there.
1. dice rolls (99 rolls make 256bits, I roll more than just 99, I do 200 rolls let's say, it is still going to be SHA256ed into 256 bits, so here i am wondering if doing more rolls helps? )
2. flip coins (256times, people say flipping coins is not secure as dice rolls? )
3. buy hexadecimal 16-face dice and roll it .
4. Use a password manager like keepass to generate HEX, then feed it to ian39 html for my seed.
5. take images and convert into entropy(any risks there? my gut feeling tells me there are unseen risks there, maybe i am wrong.)
