lkml.org 
[lkml]   [2013]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Date
Am Sonntag, 3. November 2013, 07:41:35 schrieb Theodore Ts'o:

Hi Theodore,

>On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
>
>Sandy Harris pointed out a very good paper that I would definitely
>recommend that people read:
>
>http://lwn.net/images/conf/rtlws11/random-hardware.pdf
>
>It basically describes some efforts made in 2009 by folks to do
>exactly the sort of experiments I was advocating. What I actually

I am wondering whether you have seen my last measurements where I
effectively performed the tests you were asking for: disabling all
possible CPU features and selectively enabling them.

The tests described in the above mentioned documents and much more are
all already in the test suite and test results I present here.

>think is more important, though, is not the doing of the experiments,
>but the development the tools to do these experiments. If people can
>create kernel modules (and they have to be done in the kernel, since
>you need to be able to disable interrupts, L1 caches, etc., while you
>run these tests), then it will be possible to do these experiments
>each time a new CPU comes out from Intel, or each time an ARM hardware
>vendor comes out with a new ARM SOC.

The test code is available and it is executed in kernel space.
>
>It's important that these tests are done all time, and not, "OK, we

Again, the code is there for the taking, including the analysis part.
Yes, it can be easily converted into a fully automated test such that at
the end a result of "CPU shows sufficient variations for the RNG" or
not.

Therefore, I am asking again:

- Which other CPU mechanisms can I disable that I did not so far?

- The execution time measurements when disabling CPU features show that
there is still significant variations available. Given the fact that an
adversary is not able to disable the features as I did, he will not be
able to reduce the variations induced by the features. He may alter them
potentially, but there are still variations which he cannot affect, let
alone predict. Therefore, how shall an adversary make predictions of the
variations to weaken the RNG?

I heard a nice statement from the developer who implemented the
/dev/random device of a different, respected operating system: the last
step to accept the underlying root cause of uncertainty for an RNG
always requires a leap of faith. Looking at typical noise sources that
sounds about right. For example:

- how can we be sure that nobody who measures the key stroke interrupts
can do that with a precision that is higher than the estimated entropy
the key stroke is awarded (note, an adversary has the means to observe
key strokes)? Same applies to mouse movements. Note that X11 allows you
to measure these events precisely (the xev application should give a
glimpse).

- how can we be sure that fast_pool exhibits no correlation with the
other noise sources?

- how can we be sure that the HDD fluctuations are random?

We simply accept that these issues do not allow predicting sequences to
the extent that weakens the RNG.

My goal is to give another seed source to add even more uncertainty into
the Linux RNG in addition to the existing seed sources. This would also
support environments that were typically left in the rain so far, such
as virtual machines, early boot sequences, Live CDs, or headless systems
without a spinning disk.

Ciao
Stephan


\
 
 \ /
  Last update: 2013-11-05 14:21    [W:0.172 / U:0.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site