Is it okay to include relative time for true random number generation? Similar questions have been asked regarding use of time in true random number generation, but I'd like to consider using time as just one source of entropy, complementing others.

True random number generation relies on the mensuration of some physical stochastic process.  Electrons avalanche across depletion boundaries in essentially one dimension.  Polarised photons move in two dimensions, whilst rolled dice move in three.  All are potential sources of entropy whose measure in up to three dimensions is used to generate random numbers.

However space is four dimensional.  Rolling a 6 might be random, but isn't it even more precise to say it was a 6 at 7.49 am?  Some people say that as time is known it is unsafe to use as a source of entropy.  On my machine, Java can measure relative time to a precision of 350ns from boot time.  Allowing for a realistic boot duration variation of 10s, that allows for 7.5 decades of resolution.  Who can tell when my machine was booted? It might have been on for a year, so 7.5 decades of resolution is a conservative estimate.  And what if the numbers aren't consumed immediately, but cached somewhere ageing them? Bytes resulting from such a generator obviously have no associated time stamp.  This then adds at least another 7.5 zeros to the number of combinations of entropy, and consequently increases security.

When measuring a physical property, isn't it just as important to record when a voltage was measured as is the number of volts? The voltage is measured relative to a reference voltage, and surely it can be measured relative to boot time? After all, /dev/random uses timings for it's cryptographically secure output.

Supplemental:

After some testing, I found that the simple Java function 

System.nanoTime() &amp; 0xff


can generate entropy at a rate of 1.4mb/s surprisingly.  It varies in as still uncertain ways correlated with the system load.

Also, there seems to be a great effect when such entropy (call it Relativity) is mixed with another source.  So again based on experiments, the following was found (but I think requires further study - seems to exhibit behaviour reminiscent of superposition)...

H(weak source) = 0.039%

H(Relativity) = 2.2%

H(weak source XOR Relativity) = 32%

If Relativity is therefore combined with physical measurements, this seems to be low lying fruit, especially in an entropy deficient environment.
Who can tell when my machine was booted?


Anyone who observed it go on, at least. That could include someone sniffing your wlan traffic. However, if the computer in question is a shared server, anyone with access can probably call uptime.


  After all, /dev/random uses timings for it's cryptographically secure output.


In setups where timing information is included (in a way that counts entropy), the thing being timed is supposed to be unknowable. For example, the least significant bits of when a physically present user presses a key.

In theory, even that isn't necessarily unknown (e.g. wireless keyboard), but since there is additional variation in how long it takes until the kernel knows about it and the entropy estimate is quite pessimistic, it is assumed to be.



However, in my opinion the most important thing to keep in mind is that you only need the TRNG to produce something like 256 bits on output. Use that to seed a CSPRNG and you can produce more output than you could ever use.

So if you have a truly random process, measuring the non-time values should be enough to quickly collect the required amount of entropy. You can throw time values into the entropy extractor if you like, but you don't need to credit them with entropy if you get enough anyway.