# Are the SHA family hash outputs practically random?

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.

• If some characters were consistently less "random" than others that would indicate a severe flaw in the hash function. – Thomas Jan 10 '14 at 7:14
• 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? – CL. Jan 10 '14 at 8:54

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.

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.