[cryptography] random number generator

Russell Leidich pkejjy at gmail.com
Fri Nov 21 15:14:57 EST 2014


OK, if you think my Jytter TRNG is weak, then maybe you're right. Here is
how someone can straightforwardly attempt to break it: do a WRMSR
instruction to set the timestamp counter to some constant value immediately
before running it. (Or, close enough, save the TSC value on entry to the
function, and subtract it from the TSC after every RDTSC instruction.) This
basically simulates the extreme case of coldbootness, where every machine
in the world runs Jytter with the same starting TSC. Then show us what you
find in terms of statistical bias in the 32-bit outputs.

Yes, if you simulate Jytter, you can of course create any bias you want.
The question is, is there a realistic cold boot scenario which would have
bias to an extent which would endanger security? Perhaps... let's see the
data.

BTW that's a pretty sobering paper, although I don't immediately see the
Jytter connection. Jytter doesn't naively read the timer N times or even
wait for N interrupts or N milliseconds, then assume that it has enough
entropy; nor does it depend on pseudorandomness to mask its would-be biases
(although it does use some crude pseudorandomness techniques because it
somehow has to hash the (very long) timestamp stream it observes into a
32-bit output). It looks for events which it regards as unique based the
uniqueness of their durations. It's sensistive to the permutative order and
the duration of such events, in addition to the timestamp stream itself.

So you're correct in the sense that you can never be 100% sure that some
platform out there isn't super-quiescent and therefore insecure with
respect to timing-based entropy. But then, what would be better? A
third-party hardware TRNG register that you can't trust? A quantum dot
camera, which might be broken or worn out, which is connected across a bus
that radiates frame data into the environment, and therefore might easily
leak the entropy? A "trusted platform module" which has both of these
weaknesses? If we could have an on-CPU TRNG register based on totally
unbiased quantum switches or something like that, then great, but who has
the xray and other equipment to verify that it's not just a simulation of
said TRNG? And how portable is that, unless every chip manufacturer decides
to implement it?

Russell Leidich

On Fri, Nov 21, 2014 at 5:01 PM, <dj at deadhat.com> wrote:

>
> > Rather than me listing "names", why not just let it rip and run your own
> > randomness tests on it?
>
> Because that won't tell me if you are performing entropy extraction.
>
> Jytter assumes an x86 machine with multiple asynchronous clocks and
> nondeterministic physical devices. This is not a safe assumption. Linux
> assumes entropy in interrupt timing and this was the result
> https://factorable.net/weakkeys12.extended.pdf.
>
> This falls under the third model of source in my earlier email. Your
> extractor might look simple, but your system is anything but simple and
> entropy extracted from rdtsc and interrupts amounts to squish.
>
> Looking at the timing on your system and saying "it looks random to me"
> does not cut it. Portable code has to have a way to know system timing is
> random on every platform it runs on. The above paper shows that it isn't.
>
> Jytter does something neat but the broad claims you are making and the
> broader claims the Jytter web site makes do not pass the sniff test.
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20141121/02c79d7c/attachment-0001.html>


More information about the cryptography mailing list