-2

Is a random number generated by a CSRNG equivalently secure as the SHA hash of that number? I know that RNGs generate numbers that look random, and aren't necessarily random. For example, in a range of [1, 2^256], number 100 might be picked randomly, but it isn't secure, so it needs to be changed.

However, the SHA256 hash of a number that looks random has the same chances to be 100 just like any other result. Does this mean that the SHA256 hash of a pseudo-random number is inferior in terms of security?

Angelo M.
  • 95
  • 1

1 Answers1

0

Is a random number generated by a CSRNG equivalently secure as the SHA hash of that number?

Security is not a single parameter. Equivalently secure under which requirements, under which scope and which pre-conditions?

I know that RNGs generate numbers that look random, and aren't necessarily random.

Random number generations may not produce unpredictable output, but a well seeded CSPRNG, a cryptographically secure random number generator is - of course - supposed to do that.

For example, in a range of [1, 2^256], number 100 might be picked randomly, but it isn't secure, so it needs to be changed.

Any element, when securely generated, is as secure as the next.

Note that SHA-256 generates 256 bits, which may be interpreted as a number afterwards, although we then usually assume it is in the range $[0, 2^{256})$.

However, the SHA256 hash of a number that looks random has the same chances to be 100 just like any other result.

"Looks random" is not a good assumption. 43573405478350 may "look random", but it won't ever generate the value 100.

A CSPRNG and a cryptographically secure hash such as SHA-256 should have the same probability to generate a specific number when well seeded.

Does this mean that the SHA256 hash of a pseudo-random number is inferior in terms of security?

As indicated, that mainly depends on the input. Many CSPRNG's are actually build upon hash algorithms. Adding another hash iteration probably won't do much with regards to security, assuming that you will at least feed it 256 bits of course.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • It's irrelevant because there's no practical need for >256 bits of entropy, but SHA-256 has a 256-bit output and thus can't output more than 256 bits of entropy, even if the input is >256 bits. It's tautological, but SHA-256 can't generate numbers outside the range $[0,2^{256})$, while a CSPRNG may be able to do so even if it uses SHA-256 internally. – SAI Peregrinus Oct 13 '22 at 19:58
  • In principal yes, but I wonder if the state is larger than 256 bits if the SHA-256 is used due to the hash output size. And it is questionable if it adds any security if the state is larger. – Maarten Bodewes Oct 14 '22 at 21:02
  • @MaartenBodewes, when I say "it looks random" I imply that, as far as I understand, computers generate numbers that look random, regardless of whether they're random or not. Number 100 might be picked randomly, but it is an insecure number. Hence, it won't. However, the SHA256 of a seemingly random number has the same chances to be 100 as any other. – Angelo M. Oct 15 '22 at 09:23
  • 1
    "I imply that, as far as I understand, computers generate numbers that look random, regardless of whether they're random or not" That's extremely simplified, and, in practice, flat out wrong if you're using the operating system's CSPRNG. Nowadays even entropy that is directly retrieved from the processor is used (RDRAND on AMD and Intel processors), besides entropy retrieved from the overall system (e.g. nano-second delta's from storage devices etc.). On the other hand, if you use the default RNG in many programming language API's you might end up with a non-secure time based RNG. – Maarten Bodewes Oct 15 '22 at 16:51
  • 1
    And again 100 is just one of the elements within $[0, 2^{256})$. Would you think $2^{256} - 1$ is random? Or $2^{128}$? Or $10^{50}$? Or a number consisting of all the initial digits of Pi? Or two times Pi as that's the actual circumference of a circle? – Maarten Bodewes Oct 15 '22 at 16:54