Announcement

Collapse
No announcement yet.

Bitcoin and random number generation...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    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.
    Dale

    Comment


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

      Comment


      • #23
        I just got back from sheepshead at the Senior Center. I now have even more nickels.
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #24
          Originally posted by David Clarke View Post
          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.
          The world is strange and wonderful.*
          I reserve the right to be horrifically wrong.
          Please maintain a safe following distance.
          *wonderful sold separately.

          Comment


          • #25
            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.

            Click image for larger version

Name:	Snap23535.jpg
Views:	184
Size:	357.1 KB
ID:	816647

            Comment


            • #26
              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.
              Dale

              Comment


              • #27
                > 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
                "Not my circus, not my monkeys."

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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.

                    Comment


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

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

                      Comment


                      • #31
                        From David Roberts:

                        Code:
                        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

                        Comment


                        • #32
                          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...

                          Comment


                          • #33
                            Old programmer saying: "Sometimes 'good enough' really is good enough."
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #34
                              Just had to post today's XKCD

                              Click image for larger version

Name:	d65536.png
Views:	127
Size:	52.3 KB
ID:	816692

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

                              Comment


                              • #35
                                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

                                Comment


                                • #36
                                  @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.

                                  Comment


                                  • #37
                                    Originally posted by David Roberts View Post
                                    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).




                                    Comment


                                    • #38
                                      Originally posted by David Clarke View Post
                                      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" )

                                      Comment


                                      • #39
                                        Originally posted by David Clarke View Post
                                        "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.

                                        Comment


                                        • #40
                                          Originally posted by Stuart
                                          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.

                                          Comment

                                          Working...
                                          X