23
$\begingroup$

Say I hashed the output from a random number generator (with nonce), would the resulting SHA256 hash be as random as the inputted number?

And If I used the first 5 hex characters, and then used the first 5 ignoring the very first character and so on repeating removal of the first character, would each number be just as random?

Example of what I mean, here's a 512 bit hex string.

26657320797d4f5b385d43274a246178263f3b686b645e375b45643442

Is any segment of 5 characters chosen from random locations in the string guaranteed to be a fairly random number?

I am trying to make a pretty simple random number generated based on a hashed seed.

Improve this question
$\endgroup$
2
  • $\begingroup$ If some characters were consistently less "random" than others that would indicate a severe flaw in the hash function. $\endgroup$
    – Thomas
    Jan 10, 2014 at 7:14
  • $\begingroup$ Why do you mention the nonce, when the hashed data itself is already random? If you want many numbers from your generator, wouldn't this be a counter instead? $\endgroup$
    – CL.
    Jan 10, 2014 at 8:54

2 Answers 2

Reset to default
17
$\begingroup$

Say I hashed the output from a random number generator (with nonce), would the resulting SHA256 hash be as random as the inputted number?

Let's suppose you flipped a perfectly fair coin. You flip it 1024 times to create a bit string of 1024-bits.

Because the coin is perfectly fair, this means that each strings of 0s and 1s will appear with precisely the same probability.

What happens if we apply SHA-512 to these strings? Well, in order for SHA-512 to give a completely uniform 512-bit output, it would have to be the case that if we hashed every 1024-bit string then each 512-bit hash value would have to appear precisely $2^{512}$ times.

There is no proof that SHA-512 behaves in this way. I would be very surprised if this turned out to be the case!

As such, the output of hashing a truly random stream is a stream which is bias. This bias will be very small indeed, but it will be there. So the answer to that specific question is no.

In practice, the bias is so unbelievably small that it doesn't matter. In fact, many hardware RNGs hash the entropy pool to produce output bytes.

However, it's worth noting that using such an RNG as the basis for generating a one-time-pad actually ruins the security proof! It would be technically insecure but good luck exploiting it.

Improve this answer
$\endgroup$
14
$\begingroup$

The SHA-256 (as well as any cryptographically secure hash algorithm) produces output that will appear like an uniformly random sequence to observer who does not know the input.

Quite a few random number generators, for example ANSI X9.31's RNG and NIST SP 800-90 Hash_DRBG use SHA family hash functions for the reason that resulting sequence is hard to distinguish from random.

Is any segment of 5 characters chosen from random locations in the string guaranteed to be a fairly random number?

Thus, the answer is: any consecutive five characters will appear random to casual observer, with overwhelming probability. (Also, with large probability there will be casually sequences like 99999, which do not appear random.)

But, what is the benefit you are actually looking for?

  • If the RNG is very good, and produce uniform random numbers you need no SHA-256.
  • If the RNG is able to produce entropy, but has large bias, SHA-256 is a very good function for collecting entropy. The output of the function has nearly 1 bit of entropy per output bit, if the input to the function contained at least 256 bits of entropy. Only very little entropy gets lost in this process.
  • SHA-256 using constructs like Hash_DRBG in NIST SP 800-90 can be used in situation where true entropy is available, but is slow to collect. Once you have been able to collect 256 bits of entropy (and preferable a bit more to be safe), you can use the entropy to instantiate Hash_DRBG/SHA-256, which will be able to serve billions of random numbers.

Remember these are not good uses:

  • If you feed SHA-256 with too little entropy (or even smaller input than 256 bits), the output may appear random, but it is not. Smart adversary can be able to abuse this.
  • OTP (for detail read answer from Simon).

In other words: if your input to hash is short or too predictable, so shall be the output.

Improve this answer
$\endgroup$
6
  • $\begingroup$ The benefit I'm looking for is a simple way to make a random number from 2 seeds, the benefit for me is 2 seeds in and random seeded number out. Taking the first 5 characters of the hex hash is the random number. $\endgroup$
    – John T
    Jan 10, 2014 at 21:35
  • $\begingroup$ For purpose of combining random inputs, hash functions are quite good: The output tends to be close to combination of the sources (or the output length of the hash). $\endgroup$
    – user4982
    Jan 10, 2014 at 22:16
  • 1
    $\begingroup$ If the seeds are not random, the output won't be either. If the seeds don't have at least 80 bits of entropy in aggregate, the output will have less than that. $\endgroup$
    – Stephen Touset
    Jan 11, 2014 at 2:45
  • 1
    $\begingroup$ Additionally, depending on the application, you may need to consider the possibility that either party is dishonest and uses a fixed value as their seed (reducing the total entropy, if the other seed has fewer than 80 bits of entropy). $\endgroup$
    – Stephen Touset
    Jan 11, 2014 at 4:34
  • $\begingroup$ "For observe"... this doesn't make sense to me. I'd love to edit your opening sentence for clarity, but I don't really know what you're saying. Can you clarify? Otherwise, good answer. $\endgroup$
    – Flimzy
    Jan 12, 2016 at 8:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.