From: Stephan Mueller <smueller@chronox.de>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: sandy harris <sandyinchina@gmail.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Date: Tue, 29 Oct 2013 23:25:28 +0100 [thread overview]
Message-ID: <11529328.Jgjayj3SHB@tauon> (raw)
In-Reply-To: <7861469.OAmn4h8An0@tauon>
Am Dienstag, 29. Oktober 2013, 15:00:31 schrieb Stephan Mueller:
Hi Ted,
>Am Dienstag, 29. Oktober 2013, 09:24:48 schrieb Theodore Ts'o:
>
>Hi Theodore,
>
>>On Tue, Oct 29, 2013 at 09:42:30AM +0100, Stephan Mueller wrote:
>>> Based on this suggestion, I now added the tests in Appendix F.46.8
>>> where I disable the caches and the tests in Appendix F.46.9 where I
>>> disable the caches and interrupts.
>>
>>What you've added in F.46 is a good start, but as a suggestiom,
>>instead of disabling one thing at a time, try disabling *everything*
>>and then see what you get, and then enabling one thing at a time. The
>>best thing is if you can get to the point where the amount of entropy
>>is close to zero. Then as you add things back, there's a much better
>
>I will try to do that.
>
>But please see the different lower boundary values in the different
>subsections of F.46: none of them fall when I disable or change
>anything in the base system (except the power management -- where I
>added additional analyses). Some of the changes imply that the jitter
>increases when I disable certain support.
>
>Thus, expect that we will not see a significant drop in the jitter as
>you fear or expect.
>
>Yet, I will try and report back.
Please have a look at the updated documentation, appendix F.46.10
provided in [1].
The interesting result is that some combinations of disabling CPU
support do reduce the CPU execution jitter. However, disabling all
support is not the lowest jitter measurement.
Though, none of the tried combinations deteriorate the measurement so
much that the execution jitter would be insufficient for use in the RNG.
[...]
>>sense of where the unpredictability might be coming from, and whether
>>the unpredictability is coming from something which is fundamentally
>>arising from something which is chaotic or quantum effect, or just
>>because we don't have a good way of modelling the behavior of the
>>L1/L2 cache (for example) and that is spoofing your entropy estimator.
>
>Please note: if the jitter really comes from the oscillator effect of
>the RAM clock vs. the CPU clock (which I suspect), we will not be able
>to alter the jitter software wise.
My current conclusion is that software can have some impact on the
execution jitter (as it is visible when executing different OSes on the
same hardware system as outlined in appendix F.45.
But none of the software impacts can deteriorate the jitter to the level
that it is not usable any more for the RNG and still keep the claim that
each output bit would have one bit of entropy.
[1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
Ciao
Stephan
next prev parent reply other threads:[~2013-10-29 22:25 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 18:38 [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random Stephan Mueller
2013-10-12 1:45 ` Sandy Harris
2013-10-12 3:28 ` Theodore Ts'o
2013-10-12 19:04 ` Stephan Mueller
2013-10-12 20:12 ` Stephan Mueller
[not found] ` <CACXcFm=_jmeKe2YYbHDi-jTGX-23hDsDeu_weWQkr2F_FpE_6g@mail.gmail.com>
2013-10-14 13:38 ` Fwd: " Sandy Harris
2013-10-14 14:12 ` Stephan Mueller
2013-10-14 14:26 ` Stephan Mueller
2013-10-14 14:14 ` Sandy Harris
2013-10-14 14:40 ` Stephan Mueller
2013-10-14 15:18 ` Sandy Harris
2013-10-14 15:26 ` Stephan Mueller
2013-10-14 15:46 ` Sandy Harris
2013-10-14 21:33 ` Sandy Harris
2013-10-15 6:23 ` Stephan Mueller
2013-10-28 15:40 ` Stephan Mueller
2013-10-28 16:06 ` Henrique de Moraes Holschuh
2013-10-28 16:15 ` Stephan Mueller
2013-10-28 21:45 ` Theodore Ts'o
2013-10-29 8:42 ` Stephan Mueller
2013-10-29 13:24 ` Theodore Ts'o
2013-10-29 14:00 ` Stephan Mueller
2013-10-29 22:25 ` Stephan Mueller [this message]
2013-11-02 11:01 ` Pavel Machek
2013-11-02 11:12 ` Pavel Machek
2013-11-03 7:20 ` Stephan Mueller
2013-11-03 12:41 ` Theodore Ts'o
2013-11-05 12:20 ` Stephan Mueller
2013-11-06 11:49 ` Stephan Mueller
2013-11-06 12:43 ` Theodore Ts'o
2013-11-06 12:51 ` Stephan Mueller
2013-11-06 13:04 ` Theodore Ts'o
2013-11-06 13:24 ` Pavel Machek
2013-11-07 0:36 ` Nicholas Mc Guire
2013-11-07 5:21 ` Stephan Mueller
2013-11-09 22:04 ` Clemens Ladisch
2013-11-10 1:10 ` Stephan Mueller
2013-11-10 16:31 ` Clemens Ladisch
2013-11-10 17:21 ` Stephan Mueller
2013-11-10 20:28 ` Clemens Ladisch
2013-11-13 3:12 ` Stephan Mueller
2013-11-13 11:51 ` Clemens Ladisch
2013-11-13 15:15 ` Stephan Mueller
2013-11-13 17:14 ` Pavel Machek
2013-11-14 10:51 ` Clemens Ladisch
2013-11-14 18:01 ` Stephan Mueller
2013-11-14 18:30 ` Clemens Ladisch
2013-11-14 18:34 ` Stephan Mueller
2013-11-11 2:58 ` H. Peter Anvin
2013-11-07 1:03 ` Nicholas Mc Guire
2013-11-07 5:26 ` Stephan Mueller
2013-11-09 22:04 ` Clemens Ladisch
2013-11-10 1:16 ` Stephan Mueller
2013-11-03 23:32 ` Pavel Machek
2013-11-05 12:25 ` Stephan Mueller
2013-11-05 13:45 ` Stephan Mueller
2013-11-06 11:42 ` Stephan Mueller
2013-11-06 13:26 ` Pavel Machek
2013-11-07 3:12 ` Stephan Mueller
2013-11-13 3:37 ` [PATCH] CPU Jitter RNG: Executing time variation tests on bare metal Stephan Mueller
2013-10-30 12:59 ` [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random Sandy Harris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11529328.Jgjayj3SHB@tauon \
--to=smueller@chronox.de \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandyinchina@gmail.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).