hi, i wrote the code. i am bad on writing descriptions and explanations. if you have doubts, please analyze source file test.s section f, read about sys_write, sys_open, sys_nanosleep here: http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x... and about tRNG timing jitter here: http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf .... it needs 4 ubits (32 equiprobable time deltas) per each time measurement.

A HAVEGEd-like RNG as I suspected. For your web page, just modify it to say that "Its entropy comes from CPU execution-time jitter like HAVEGEd does." People familiar with such generators will instantly know what to expect. I did one of these many years ago in a more blunt, simple, and imprecise form. It was a hack. I get the motivation but was concerned about relying solely on it.

The reason is mentioned in the paper you link. The CPU's and programs are deterministic machines. They appear to have non-deterministic behavior when facing unknown combinations of instructions during execution of the system. I believed it would do fine on a system with unpredictable workloads. However, there's two things remaining that could make entropy low: a predictable workload such as an embedded, real-time system; starting state of system executing same calls in same order on same hardware might not produce the amount of non-determinism in the paper. The first isn't important to your use case in all likelihood but the second might be.

My solution was to use a real TRNG to produce the seeds. Then, one of the things the RNG would do over time is replace those seeds with something random. That way it always has a truly or very random start. This also helps in real-time embedded assuming the low-priority task doing this ever gets executed. If you have no TRNG, I had two strategies for that: rolling 8-sided D&D die in a shoebox given 8 numbers maps to 3 bits perfectly; shuffling cards good, type them into text box in order, and repeat that once or twice. Whether die, cards, or both, you type the numbers into a text field or text file that you hash with SHA-256. Incidentally, this is also how I generated my TrueCrypt passwords as a BASE64-encoded version of SHA-256 hash is 64 characters.

So, start with truly random seed, occasionally replace the seed, run your numbers through a CPRNG regardless to avoid repetition in the bits that TRNG's sometimes do, and log as much of the TRNG output as possible (millions of bits minimum) to run through as many tests as possible. Might also make a nice experiment to test my hypothesis about how much it passes randomness tests during system startup from power off to the point TRNG is ready for delivering numbers. Do that 30 times or so to compare against what randomness looks like in a system that's been running a while.

Note: All of this shouldn't get too much fixation as a HAVAGEd-style RNG will be the last way they own you. They'll use an exploit or bad configuration first.

instead of talking with words, i talk with facts. whenever you have the proof, that pandom doesn't offer 64 ubits / 64 bits, please contact me. you have to work with test.s have a nice day and good luck :D

You've measured the internals of Intel processors and their interactions with inits or other homogenous workloads to have "facts" backing your claim of real entropy vs apparent entropy? That's pretty impressive if you don't work at Intel. I'm guessing you're not working with "facts" at all so much as guesses based on looking at output of a black box with a limited sample of workloads.

Good news for you, as I said before, is that beating your RNG is harder than just finding a 0-day in your system. It won't break because (a) low uptake and (b) economics of hitting something else. ;)

hi, proofs of unpredictability are inside pandom/amd64-linux/proofs folder and were generated using make install-kern, running linux with parameters rw init=/usr/lib/pandom/kern