[Cryptography] Use process ID in mixing?

[John Denker]

On 03/18/2014 12:48 PM, Sandy Harris wrote:
> A process ID is only a few bits long and in many cases is quite
> predictable; it is entirely useless as an entropy source.

Agreed.

>  However, I wonder if it could play a role analogous to salt

Yes, it can ... but the time-of-day clock has all the
same strengths and fewer weaknesses.

You can use concat(clock,PID) if you feel like it.

> This can do no harm, but does it do any perceptible good?

The word "random" means different things, depending on
context.
 -- At one extreme, in non-adversarial situations, the PRNG 
  does /not/ need to be resistant to cryptanalytic attack.

Specific example:  When I am doing physics, e.g. molecular
dynamics simulations, I use one of the C (or C++) library
randomness functions, and seed it from the clock.  The
upside is that this is more widely portable than trying
to read from /dev/u?random.  I'm pretty sure the molecules 
are not going to mount a cryptanalytic attack against the 
PRNG.

 -- At the other extreme, in high-stakes adversarial situations, 
  there are really no options other than seeding the CSPRNG
  with genuine entropy from a high-quality HRNG ... or just 
  using the HRNG directly.

  Still, though, there are situations where a well-seeded
  PRNG can benefit from salting or stirring.

The PID idea does not apply to the kernel itself, especially
during the critical start-up phase.  However, the time-of-day
clock can be -- and should be -- used to salt or stir the
state of the PRNG.  This provides some less-than-ideal but
still valuable protection against replay attacks, especially
in situations where the machine has not had a chance to
update the PRNG seed and write the seed to persistent
storage somewhere.

The previous paragraph is dependent on having each machine 
be /provisioned/ with a unique, secret seed for the PRNG.
This is not always done.  IMHO there reeeeeally needs to
be a best-practices document that emphasizes the importance
of proper provisioning.

This is discussed in more detail at
  http://www.av8n.com/computer/htm/secure-random.htm