It obtains seed and random numbers by reading system files such as the special device files /dev/random and /dev/urandom. This implementation respects the securerandom.source Security property and java.security.egd System property for obtaining seed material. If the file specified by the properties does not exist, /dev/random is the default seed source. /dev/urandom is the default source of random numbers.

On some Unix platforms, /dev/random may block until enough entropy is available, but that may negatively impact the perceived startup time. By selecting these sources, this implementation tries to strike a balance between performance and security.

generateSeed() and setSeed() attempt to directly read/write to the seed source. However, this file may only be writable by root in many configurations. Because we cannot just ignore bytes specified via setSeed(), we keep a SHA1PRNG around in parallel.

nextBytes() reads the bytes directly from the source of random numbers (and then mixes them with bytes from the SHA1PRNG for the reasons explained above). Reading bytes from the random generator means that we are generally getting entropy from the operating system. This is a notable advantage over the SHA1PRNG model, which acquires entropy only initially during startup although the VM may be running for months.

Also note for nextBytes() that we do not need any initial pure random seed from /dev/random. This is an advantage because on some versions of Linux entropy can be exhausted very quickly and could thus impact startup time.

Finally, note that we use a singleton for the actual work (RandomIO) to avoid having to open and close /dev/[u]random constantly. However, there may be many NativePRNG instances created by the JCA framework.