
CPU Jitter Based True Random Generator - billconan
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
======
qrmn
Isn't this basically another take on HAVEGE[1]? I'm not sure I'd call that a
true random source.

[1]
[https://www.irisa.fr/caps/projects/hipsor/;](https://www.irisa.fr/caps/projects/hipsor/;)
see [http://www.issihosts.com/haveged/](http://www.issihosts.com/haveged/)

~~~
AlyssaRowan
As I've said before: look out for side-channels!

The RF/electrical/other emissions from general-purpose CPU cores and their
supporting circuitry tend to have major features with good correlations to
execution timing and pipeline stalls, which they are not designed to treat as
secret.

This is one reason why crypto implementations should be written using
techniques that avoid table lookups or branches based on secret data: another
is of course that the resulting timing variations may be visible on another
core, over a network, etc.

Systems which treat the TSC (etc) as such secret data that they effectively
seed a PRNG with it should therefore be treated with a very considerable
degree of caution considering just how (literally) squeaky some cores/boards
can be about leaking it. Further research is needed.

------
pc2g4d
(Having read the beginning and skimmed the rest) my impression is that this is
a useful but vulnerable technique. Useful in that it provides an entropy
source not currently available. But vulnerable in that it could conceivably
weakened considerably.

Perhaps what should be discussed in this context is not entropy but
conditional entropy. Entropy really is relative to one's understanding of the
underlying system being observed. For example, human height is nearly normally
distributed and would provide some degree of entropy if it could be freely
sampled from. But for a given person, knowledge of the parents' heights makes
predicting the child's height a much easier task. The entropy of height given
parents' heights is less than the entropy of height in general.
H(Height|ParentsHeight) < H(Height)

In the case of this CPU jitter method, things it calls nondeterministic are,
in fact, clearly deterministic---disparities between CPU and memory clockspeed
come to mind. Effort at better modeling of the internals of a CPU may lead
these "random" events to appear not-so-random-anymore. Suppose I build a
statistical model of CPU jitter based on various properties observable from a
non-privileged process in the OS. To the extent that my model predicts jitter
better than random, an entropy source derived from CPU jitter is weaker. The
conditional entropy _given_ the model could decrease substantially, to the
point that it's no longer a good entropy source.

That said, none of that work seems to have been done yet. But I wouldn't
consider this a bulletproof entropy source in the long run.

------
osandov
Great article on LWN about this:
[http://lwn.net/Articles/642166/](http://lwn.net/Articles/642166/)

------
tedunangst
Wow, this is pretty thorough but I never saw it address the simple question,
why not use rdrand?

Also:

> the CPU Jitter random number generator returns roughly 10 kBytes per second
> on an Intel Core i7

OpenBSD requires at least 8 bytes of random data per TCP connection. Limiting
a system to 1000 conn/sec (to say nothing of any other processing those
connections may require) probably isn't going to fly.

As a comparison, I can read from /dev/random (and write to /dev/null) at over
300 MB/s.

~~~
hurin
> OpenBSD requires at least 8 bytes of random data per TCP connection.
> Limiting a system to 1000 conn/sec (to say nothing of any other processing
> those connections may require) probably isn't going to fly.

They can use the generated random values to seed a CSPRNG. I guess for
containers or other virtual environments this has distinct advantages (at
least that's one of the reasons given in the introduction).

> As a comparison, I can read from /dev/random (and write to /dev/null) at
> over 300 MB/s.

You can read from /dev/random only if there is enough entropy in it, and it's
rarely very much, I don't know how you got that 300MB/s figure.

~~~
tzs
He mentioned OpenBSD. On OpenBSD /dev/random is a CSPRNG.

~~~
hurin
I think I need to sleep.

------
salibhai
Someone please ELI5 this?

~~~
valarauca1
Basically thread scheduling is an imperfect art. So when you tell a thread to
sleep for 4ms, it may sleep for 1-16ms depending on other threads work load,
resource contention, etc.

This is a huge problem if you work in very precise time sensitive data (I do
ISO17025 flow calibration systems), and when you start needing >100 data
points per second, of dynamic IO you will run into millisecond timing issue
standard time shared OS's will introduce. The solution to this is Real-Time
OS's (not Real-Time webdevelopment) that handle scheduling differently, and
prioritize IO tasks even higher. But most of these suck.

:.:.:

This random noise (from the scheduler) is a pretty good source of entropy (and
the only assumption is your Unix box has other processes, that are using
resources). Because your process, generally has no clue that hundreds of other
processes are inflight and also being executed at the same time.

So their interference, is effectively magic data from nowhere.

Dan Kaminsky did a talk at Defcon last year where he mentioned the need for
this type of CSRNG [1]

I even tooled up a very basic (and flawed) implementation a few months ago to
play with the notion [2]

[1]
[https://www.youtube.com/watch?v=xneBjc8z0DE](https://www.youtube.com/watch?v=xneBjc8z0DE)

[2] [https://github.com/valarauca/Simple-
CSRNG](https://github.com/valarauca/Simple-CSRNG)

~~~
hurin
Is there a significant advantage? Either-way you just need to fill /dev/random
enough for /urandom to be well seeded.

~~~
valarauca1
Yes.

Interprocess scheduling isn't currently a source of entropy for /dev/random or
/dev/urandom.

Edit: I have random/urandom backwards. Still doesn't change my core point.
Sorry for the confusion.

/dev/random is a PRNG, and predictable. You shouldn't use it for security
applications but only for specific state/algorithm randomness.

/dev/urandom requires hardware noise/key events, etc. to generate its entropy.
These become hard to find when your dealing with purely virtualized
installations.

:.:.:

The key focus for this is webapps, or should be. Far to many use PRNG to give
session cookies, and these are very very easy to hyjack especially if cookies
can be issued whenever a user logs in/out. Its pretty trivial to generate
1,000 -> 5,000 session cookies (from login/logout) and attempt to find a PRNG
pattern.

~~~
garrettr_

      /dev/random is a PRNG, and predictable. You shouldn't use it for security applications but only for specific state/algorithm randomness.
      /dev/urandom requires hardware noise/key events, etc. to generate its entropy. These become hard to find when your dealing with purely virtualized installations.
    

This is not true, at least on Linux. /dev/random is actually closer to what
you describe as /dev/urandom. It is a cryptographically strong randomness
source that blocks depending on the state of its internal "entropy pool".
/dev/urandom is also a cryptographically strong randomness source (seeded from
/dev/random), but it does not block.

Here's a great blog post with more info: [http://www.2uo.de/myths-about-
urandom/](http://www.2uo.de/myths-about-urandom/)

~~~
tptacek
On the BSDs, there's no real distinction between the two, and the names are
just there for compat.

