
Pandom – True random number generator - eth0up
http://ncomputers.org/pandom
======
nickpsecurity
I have no idea what this is. It has no description of how it works on
homepage. That it's just software makes me doubt it's a TRNG in first place.
The code is assembly I can't read. I suggest people staying clear of this
thing.

~~~
ncomputersorg
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...](http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/)
and about tRNG timing jitter here: [http://www.chronox.de/jent/doc/CPU-Jitter-
NPTRNG.pdf](http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf) .... it
needs 4 ubits (32 equiprobable time deltas) per each time measurement.

~~~
nickpsecurity
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.

~~~
ncomputersorg
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

~~~
nickpsecurity
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. ;)

~~~
ncomputersorg
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

------
ncomputersorg
installation tutorial here: [https://www.howtoforge.com/tutorial/how-to-
install-pandom-a-...](https://www.howtoforge.com/tutorial/how-to-install-
pandom-a-true-random-number-generator/)

