If I have a headless machine (no mouse movements, no keyboard presses, or user input), without any cryptography CSPRNG APIs, where can I collect entropy from?
I believe that on any CPU that you should be able to find at least two sources of noise with physically proven behaviors to create a purely random number. The first is through oscillator sampling, assuming that you have a fast clock and a slow clock. The second assumes that you have DRAM, and through the two-way shot noise in the channel, you should be able extract random bit flips in DRAM if you can control the timing.
The clock in a system is not a precise as you'd hope. Generally, you have a core clock that is generated through a PLL, and you also have some sort of realtime clock at 32.768kHz because that will overflow after bit-15 to give you a 1-second pulse. By sampling the fast clock with the slow clock, you can generate a series of bits; however, there's a few caveats:
- oscillator jitter alone is not enough to create randomness
- you can actually degenerate the randomness by trying to make it random if you have a poor circuit model.
As an x86 was mentioned (I know the least about this CPU btw), the time stamp counter combined with a 8254 on older machines or HPET on newer machines will get you a fast and a slow clock source. Michael S. McCorquodale dissertation should have a very good analysis on the clock jitter in both cases, or at least he did at this defense.
If you can control the timing of the DRAM, you very likely could get a random noise source due to the fact that the noise in a semiconductor channel is a function two-way shot noise (and not classical Johnson Noise). Let's limit the scope to a single bit. You would have to put charge on the DRAM capacitor and then gradually delay the timing until that bit gave you a 1 or 0. The charge amplifier on the DRAM rows would also add to the noise, but I will ignore that component for now. Carver Mead and Rahul Sarpeshkar both use shot-noise in their neuromorphic engineering papers as a source for entropy on silicon neurons, and circuits people can derive it but I really don't know where an external reference is. The caveats:
- DRAM timing control
- assume that you are not near "freeze out" as the shot noise goes away.
I believe that either of these, combined with a hash, could be used as a means to generate a true random number as the noise sources are rooted in physics. You'll need to grab a cryptographer to take what I described to the next step.
Can entropy be gathered in a system without any hardware dependencies?
No. Not real entropy. There's probably some over-used cliche about trying to, but essentially you can't create Kolmogorov randomness without physical processes.
But there's a but. All computer algorithms execute on hardware, and that hardware is non deterministic at the pico scale. Hard to predict execution paths, indeterminate gate propagation delays and even electron travel times, amongst others can all produce randomness for harvesting. The haveged algorithm attempts this. Even simply reading the system clock repeatedly in a high level garbage collecting language [e.g. Java's
System.nanoTime()] is non deterministic.
It's gets even more jittery if you can include a spinning disc drive in the loop somewhere. And don't forget that even virtualised discs are mounted on physical ones.
Are there any reliable entropy sources?
I suggest not very. All of the algorithms above have to execute alongside other code, some of which may be unknown, and certainly at unknown locations. It it difficult to quantify how much randomness your algorithm may have harvested, and that directly undermines the security confidence. And the concept of code portability/cross platform operation is at odds with a harvesting algorithm tied to particular hardware. So it's difficult to get 128 bits of Kolmogorov randomness in a firm timescale. You will have to use a large safety factor (say x100) in estimating min.entropy, but it's doable if speed isn't important. You'll be down to only tens of bits/s on something like an Arduino.
There are even more exotic techniques such as reading DRAM state transitions. There's a 2018 summary of DRAM based cryptographic primitives here, from TRNG and physical unclonable function (PUF) perspectives.
If your machine has some form of remote/comms access, then you can just fetch entropy over the comms port from a device that has it to spare.