Benefits of hashing a particular seed in a PRNG

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

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.