This question is linked with this question (stackoverflow) where I asked about a specific implementation detail of Python's random number generator (Mersenne Twister). Here, I have a slightly different focus. Feel free to close, but I could not find a similar question which exactly answered my question

  • In a PRNG what would be the benefit of hashing a particular seed (user provided)?
  • Would there be any additional benefits if salt were applied?

For instance in Pythons case they do both, where the salt used is the seed itself.

EDIT: I am asked about a use case which I find hard to answer? Studying the implementation of several PRNG in several popular languages, seems to always hash / salt / modify the seed provided by their users. See for instance https://github.com/python/cpython/blob/a57ec7a4feaf24f470a9d1e5b1b3f2cb1b062af7/Lib/random.py#L157

Since most languages seem to do this, I am asking why they hash the users seed instead of simply parsing it into the PRNG

  • $\begingroup$ Does this answer your question? Properties of PRNG / Hashes? $\endgroup$ Commented Jan 26, 2022 at 13:05
  • $\begingroup$ @AleksanderCH Sadly it does not, the question asks about the benefit of always hashing the seed. (Which I could see if you pipe in the time or sometihing else) Here I am asking which benefits it would have when we are setting the seed manually. $\endgroup$ Commented Jan 26, 2022 at 13:36
  • $\begingroup$ what is the use case for such a practice? you need to give more details in the question $\endgroup$
    – kodlu
    Commented Jan 26, 2022 at 14:18
  • 2
    $\begingroup$ A PRNG should output the same sequence for a given seed. A CSPRNG shouldn't, if it takes a user-controlled seed at all it should mix it with other sources of entropy before use. The Python you linked is regular PRNG, it's just hashing the input to ensure it has the right number of bytes for the following operations. $\endgroup$ Commented Jan 26, 2022 at 17:22
  • $\begingroup$ @SAIPeregrinus Re. "A CSPRNG shouldn't". Are you sure? Is there any chance that you're conflating a CSPRNG with a TRNG? ChaCha, SecureRandom and all block cipher based RNGs are considered CSPRNGs. Yet they're all deterministic. $\endgroup$
    – Paul Uszak
    Commented Jan 27, 2022 at 13:04

1 Answer 1


When we're seeding any sort of PRNG, we may have data which is non-uniform in its entropy. For example, maybe our only source of cryptographically secure randomness is a set of random string-form UUID. However, in most PRNG implementations, we want our randomness to be uniform and of a fixed size. In order to get that, we need some sort of way to distill the input into the appropriate size, and a hash function is an easy way to do that.

When we have a non-cryptographic PRNG, the input the user provided may often be of any size, and it's often helpful to allow the user to provide an arbitrary seed. For example, some video games permit you to seed their PRNG with arbitrary text to replay the same game, and that would need to be distilled into a suitable input, for which a hash function is a good fit. Salt in this case wouldn't be as useful since the goal is to produce a deterministic result.

When we use a CSPRNG, the algorithm we use is deterministic, but we want to seed it with inputs of sufficient entropy to ensure its output is unguessable. That is, our goal is non-deterministic output. Some designs choose to force the inputs to be of uniform entropy, but most designs use some sort of derivation function, like the one used by CTR_DRBG, to allow non-uniform inputs. Sometimes those algorithms are based on a hash function, and sometimes they are not. For example, CTR_DRBG uses a block cipher-based derivation function to make the entire algorithm implementable with solely an AES implementation. The HMAC_DRBG uses HMAC in this role, which is hash based.

The DRBG designs do permit a salt or personalization string to be used, and it's often recommended. A fixed or non-random salt will not improve security if there's insufficient entropy, since we assume salt is public, but there are contexts in which it can be useful, such as if multiple DRBGs must be seeded from the same entropy inputs.

There are some cases in which we do use a CSPRNG design for deterministic output that is indistinguishable from random, and salt is useful there. For example, in RFC 6979, which describes deterministic DSA and ECDSA, we use an HMAC_DRBG to create the random value $ k $. The private key is our entropy input and the hash of the message is the salt, and both of those are required for security.


Your Answer

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

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