Bitcoin and random number generation...

[Dale Yarker]

I remember reading that passing something through a hash twice actually can make it less secure.

Probably reading about DES, maybe AES, it is an encryption weakness; not a hash weakness that I've heard of. So, we had Triple DES to extend it's usefulness.

[David Clarke]

"Who needs Bitcoin anyway?" Is there a Dairy Queen near you Michael? I hear they are going to take Bitcoin!

[Michael Mattias]

I just got back from sheepshead at the Senior Center. I now have even more nickels.

[Kurt Kuzba]

Stuart

Would you use the number as it was sent by the web site or would running that through sha-256 be a good idea, or a bad idea!

I remember reading that passing something through a hash twice actually can make it less secure.

Again - my goal is to generate Bitcoin private keys.

A secure key is just one that nobody can guess.
I would just use 01010101010101010110101 to 256 bits.
Nobody is going to guess that I wouldn't be using the most sophisticated and obscure RNG.

[David Clarke]

I am still thinking that this should not be all that difficult. The end result is simply a 256 binary string. No matter what fancy method you use - the end result is still just a 256 bit string.
Even Stuarts "Quantum Random Numbers" are expressed as 256 bits.

With all due respect to Dale - How can 256 coin toss not result in a random string of bits? I have spent a bunch of time reading about entropy in the past few days... I do this out of curiosity more than a need to write software. I see things like : Along with a standard RNG method, programming languages usually provide a RNG specifically designed for cryptographic operations. This method is usually much more secure, because it draws entropy straight from the operating system. The result of such RNG is much harder to reproduce. You can’t do it by knowing the time of generation or having the seed, because there is no seed. Well, at least the user doesn’t enter a seed — rather, it’s created by the program.

I think the entire issue here is not to have some pattern that can be linked to something like the time the key was made. So I still can't see how simply creating a string of bits using true randomness is not a simple task. You have to make 256 0 or 1 choices randomly. For example - determine if the temperature in 256 locations is odd or even. Or goto https://globe.adsbexchange.com/ - get the current latitude of 256 planes and determine odd and even latitudes.

Now to be clear I am not talking about creating a public key from a private one, Bitcoin uses the ECDSA, or Elliptic Curve Digital Signature Algorithm. More specifically, it uses one particular curve called secp256k1.


From https://www.freecodecamp.org/news/ho...-7ad0f4936e6c/

What exactly is a private key?
Formally, a private key for Bitcoin (and many other cryptocurrencies) is a series of 32 bytes. Now, there are many ways to record these bytes. It can be a string of 256 ones and zeros (32 * 8 = 256) or 100 dice rolls. It can be a binary string, Base64 string, a WIF key, mnemonic phrase, or finally, a hex string.

How many attempts needed to guess a 256 bit number?
For a brute force check,a maximum of 2^256 attempts would be required to guess a 256-bit key. This is an overwhelmingly large number, which makes such brute force cracking thoroughly impractical. Other techniques that reduce the space of possible keys to a manageable number are required, such as discovering a weakness in the generation of the keys that rules out large swaths of the possible key space, or simply figuring out how to steal the key directly.

[Dale Yarker]

I never said coin toss was not random. The code in post 9 is not strongly random. The bold text above about entropy is nonsense.

[Eric Pearson]

> How can 256 coin toss not result in a random string of bits?

FWIW, coins do have a favored side, depending on 1) which side was up before the toss and 2) the stamped pattern on both sides, which inevitably throws off the center of gravity and aerodynamics. Imagine a perfectly flat, smooth coin that always starts heads-up and is always flipped (in a vacuum) with exactly the same amount of force. It would theoretically land the same way every time. If you try to randomize which side is up before the toss, or the force of the toss, then it becomes circular: you need a random number to create a random number.

The effect is very small, but the outcome is not 50-50. For that you have to get down to the quantum level.

If you spin a coin instead of flipping it, the increased rotation speed amplifies the effects. With a US nickel it's not hard to get consistent results of 51/49.

ADDED: "A spinning penny will land as tails about 80 percent of the time, Diaconis says, because the extra material on the head side shifts the center of mass slightly." source

[David Clarke]

Ok Eric - you have convinced me actual coin toss is not random enough.

NIST suggests....

1.1.1 Randomness
A random bit sequence could be interpreted as the result of the flips of an unbiased “fair” coin with sides that are labeled “0” and “1,” with each flip having a probability of exactly ½ of producing a “0” or “1.” Furthermore, the flips are independent of each other: the result of any previous coin flip does not affect future coin flips. The unbiased “fair” coin is thus the perfect random bit stream generator, since the “0” and “1” values will be randomly distributed (and [0,1] uniformly distributed). All elements of the sequence are generated independently of each other, and the value of the next element in the sequence cannot be predicted, regardless of how many elements have already been produced. Obviously, the use of unbiased coins for cryptographic purposes is impractical. Nonetheless, the hypothetical output of such an idealized generator of a true random sequence serves as a benchmark for the evaluation of random and pseudorandom number generators.

1.1.3 Random Number Generators
RNGs) The first type of sequence generator is a random number generator (RNG). An RNG uses a nondeterministic source (i.e., the entropy source), along with some processing function (i.e., the entropy distillation process) to produce randomness. The use of a distillation process is needed to overcome any weakness in the entropy source that results in the production of non-random numbers (e.g., the occurrence of long strings of zeros or ones). The entropy source typically consists of some physical quantity, such as the noise in an electrical circuit, the timing of user processes (e.g., key strokes or mouse movements), or the quantum effects in a semiconductor. Various combinations of these inputs may be used. The outputs of an RNG may be used directly as a random number or may be fed into a pseudorandom number generator (PRNG). To be used directly (i.e., without further processing), the output of any RNG needs to satisfy strict randomness criteria as measured by statistical tests in order to determine that the physical sources of the RNG inputs appear random. For example, a physical source such as electronic noise may contain a superposition of regular structures, such as waves or other periodic phenomena, which may appear to be random, yet are determined to be non-random using statistical tests. For cryptographic purposes, the output of RNGs needs to be unpredictable. However, some physical sources (e.g., date/time vectors) are quite predictable. These problems may be mitigated by combining outputs from different types of sources to use as the inputs for an RNG. However, the resulting outputs from the RNG may still be deficient when evaluated by statistical tests. In addition, the production of high-quality random numbers may be too time consuming, making such production undesirable when a large quantity of random numbers is needed. To produce large quantities of random numbers, pseudorandom number generators may be preferable.

[David Clarke]

I think what I keep hearing is the word "FAST" as part of the requirement. And naturally lots of talk about computers. However, if for a moment we remove computers from the discussion then I would think there are all sorts of truly random things all around us.

It is possible to generate truly random numbers?
Random numbers are generated from random unpredictable processes like thermal or atmospheric noises, cosmic radiations, etc.

I think the key here is to have an external source ofentropy and use the computer to "write it down". However, unless I am missing something there is a chance the same number could be generated by even the most random generator - given a limited domain and infinite time...

BTW - This is why when I play lotto I play the same number twice. It is not unheard of for two people to win the same lotto! --- I digress.

[David Clarke]

The Windows 10 random number generation infrastructure: https://aka.ms/win10rng

Is BCryptGenRandom function (bcrypt.h) not good enough?

[David Clarke]

From David Roberts:

FUNCTION PBMAIN
LOCAL hRand AS DWORD
LOCAL Result AS INTEGER
LOCAL j, i, tot AS LONG
LOCAL RC AS LONG

BCryptOpenAlgorithmProvider(hRand, $$BCRYPT_RNG_ALGORITHM, $$NUL, 0)
FOR j = 1 TO 10000
FOR i = 1 TO 2^16
RC = BCryptGenRandom(hRand, VARPTR(Result), 2, 0)
IF Result = 0 THEN EXIT FOR
NEXT
tot += i
NEXT
PRINT tot/10000
BCryptCloseAlgorithmProvider(hRand, 0)
PRINT "done"
WAITKEY$
END FUNCTION

[David Clarke]

More on BCryptGenRandom:

https://wiki.sei.cmu.edu/confluence/...random+numbers

How about calling BCryptGenRandom 1000 times the pushing those results through SHA256?

One thing I have seen is there are almost no people making hardware random generators these days...

[Michael Mattias]

Old programmer saying: "Sometimes 'good enough' really is good enough."

[Stuart McLachlan]

Just had to post today's XKCD



The pop-up text says: They're robust against quantum attacks because it's so hard to make a quantum system that large.

[David Clarke]

Nice cartoon Stuart!

Perhaps I am just a stubborn old nut - - but I sure would figure one could make truly random numbers in a explainable way.

Since there are only two states per bit - I would figure there should be some way to do "heads / tails" 256 times randomly.

"Undoubtedly the visually coolest approach was the lavarand generator, which was built by Silicon Graphics and used snapshots of lava lamps to generate true random numbers."

i ORDERED ONE OF THESE TO PLAY WITH:
https://ubld.it/truerng_v3

[David Roberts]

@David Clarke

See your post here and my response.

Perhaps you did not see my response.

My code above was taken out of context from Jerry Wilson's thread. It is utterly pointless to call BCryptGenRandom more than once except in the context of Jerry's thread.

Intel's RdRand is your best bet – it is a lot faster than plugin hardware generators and a lot cheaper.

[Stuart McLachlan]

Intel's RdRand is your best bet – it is a lot faster than plugin hardware generators and a lot cheaper.

For a one-off private key for cryptocurrency, I still don't see a problem with RND(). After all, you are only going to be using it once (or maybe a few time if you want several wallets) and no attacker is going to know what you used to generate your key nor are they ever going to see it to look for a pattern in the bits (If they ever see it, it's no longer a private key and they don't need to reverse engineer it).

[Stuart McLachlan]

Nice cartoon Stuart!

Perhaps I am just a stubborn old nut - - but I sure would figure one could make truly random numbers in a explainable way.

Since there are only two states per bit - I would figure there should be some way to do "heads / tails" 256 times randomly.

"Undoubtedly the visually coolest approach was the lavarand generator, which was built by Silicon Graphics and used snapshots of lava lamps to generate true random numbers."

i ORDERED ONE OF THESE TO PLAY WITH:
https://ubld.it/truerng_v3

So what are your potential applications that require generating squillions of random numbers? ('cos that sort of device is only useful if you regularly need lots of totally unbased "random numbers" )

[Stuart McLachlan]

"Undoubtedly the visually coolest approach was the lavarand generator, which was built by Silicon Graphics and used snapshots of lava lamps to generate true random numbers."

Nope. It just generated a single random seed number to initialse a plain old pseudo-random number generator.

[David Roberts]

For a one-off private key for cryptocurrency, I still don't see a problem with RND().

I can think of many uses of Rnd which are OK. I can think of many uses of Rnd which are not OK. However, with RdRand I don't have to think – I know that I am getting random numbers.

I take the view that if someone has to think whether Rnd is good enough or not, then they could be in trouble.

Added:

We have a similar situation with SHA1; which is no longer recommended by the NIST. However, there are uses where it is OK. If we have to think whether it is good enough or not, then we could be in trouble. If we use SHA256, with a security strength of 128 bits, we don't have to think.