On Tue, Mar 18, 2014 at 03:48:09PM -0400, 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. However, I > wonder if it could play a role analogous to salt in a password > algorithm or the suggestion of stirring things like MAC addresses into > the pool at startup just so every machine does it slightly > differently.
Yes. Note that everything usable to fingerprint a machine can be used to uniquify the instance. HDD IDs, UUIDs of all kinds, hardware IDs, CPUIDs, you name it. > On Linux, you can get the caller's pid from kernel code with #include > <linux/sched.h> then look at current->pid. Probably there is something > similar for other systems and quite possibly there is other usable > data in the struct; I haven't looked. > Is it worth salting every call to (u)random? Mix the pid into the > output or the pool. This can do no harm, but does it do any > perceptible good? Why just PID? Why not timestamp (with maximum resolution). I've always thought opportunistic mixing is useful. For that matter, in kernel land you could include ephemeral areas of memory in the hash. For example, buffer regions (disk and network) and other areas that change during operation. You could even include network traffic (as mentioned in a followup) or CNN headlines. As long as you don't update entropy measures, it does no harm, and can do good (if unpredictable to adversary). If you never use /dev/random and just /dev/urandom, then entropy counts don't matter anyway. -- http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS
pgpmC9fLkZ5S4.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
