From: Stephan Mueller <smueller@chronox.de>
To: "Theodore Ts'o" <tytso@mit.edu>, "Jörn Engel" <joern@logfs.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Linux Kernel Developers List" <linux-kernel@vger.kernel.org>,
macro@linux-mips.org, ralf@linux-mips.org, dave.taht@gmail.com,
blogic@openwrt.org, andrewmcgr@gmail.com, geert@linux-m68k.org,
tg@mirbsd.de, sandyinchina@gmail.com
Subject: [RFC PATCH 0/5] CPU Jitter RNG
Date: Tue, 04 Feb 2014 13:36:59 +0100 [thread overview]
Message-ID: <2039634.jSmQAS6tdi@myon.chronox.de> (raw)
Hi,
with the previous release of the CPU Jitter RNG ([1]), concerns were raised on
the presence of entropy in the CPU execution timing. With this new version of
the CPU Jitter RNG, a new noise source based on memory access timings is now
added and the concerns raised before are addressed with additional analyses
given in [2] section 6.1.
This additional noise source is again covered with extensive testing
documented in [2] section 6.2. The test results allowed the explanation of the
basics of that memory access noise source.
To analyze the two noise sources, a bare metal testing program is used as
documented in [2] section 6.3. That bare metal testing allows the analysis of
the noise source without interference of an OS and interrupts.
Furthermore, for the already existent noise source of the CPU execution
timing, more analysis of the behavior of the CPU is provided in [2] section
6.1. The analysis, however, showed CPU behavior that cannot easily be
explained. The testing shows that there is a possibility to eliminate the CPU
execution timing jitter for one particular measurement using a serialization
instruction. That elimination of timing jitter, however, was not visible when
the individual rounds of the RNG were tested. That means that the elimination
of timing jitter in one special case did not show any effects on the behavior
of the RNG.
The following set of patches integrate the CPU Jitter RNG as a fallback noise
source into /dev/random. The reason for using it as a fallback only is the
conceptual difference of the CPU Jitter RNG to the other noise sources: all
other noise sources are a push mechanism whereas the CPU Jitter RNG works by
pulling bits on demand. Due to the speed of the Jitter RNG, it has the
capability of monopolizing all other noise sources which is prevented by only
invoking it when the lower entropy threshold of the Linux RNG is reached.
Ciao
Stephan
[1] http://thread.gmane.org/gmane.linux.kernel/1577419/focus=1586212
[2] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
--
| Cui bono? |
next reply other threads:[~2014-02-04 12:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 12:36 Stephan Mueller [this message]
2014-02-04 12:39 ` [PATCH 1/5] " Stephan Mueller
2014-02-04 12:40 ` [PATCH 2/5] CPU Jitter RNG: Enable compilation Stephan Mueller
2014-02-04 13:39 ` Geert Uytterhoeven
2014-02-04 16:19 ` Stephan Mueller
2014-02-04 16:39 ` Hannes Frederic Sowa
2014-02-04 16:50 ` Hannes Frederic Sowa
2014-02-04 16:53 ` Stephan Mueller
2014-02-04 17:15 ` Hannes Frederic Sowa
2014-02-04 12:40 ` [PATCH 3/5] CPU Jitter RNG: integration with /dev/random Stephan Mueller
2014-02-04 12:41 ` [PATCH 4/5] CPU Jitter RNG: provide status proc files Stephan Mueller
2014-02-04 12:42 ` [PATCH 5/5] CPU Jitter RNG: add read/write sysctls Stephan Mueller
2014-02-04 17:08 ` [RFC PATCH 0/5] CPU Jitter RNG Theodore Ts'o
2014-02-04 19:06 ` H. Peter Anvin
2014-02-04 19:23 ` tytso
2014-02-04 19:39 ` Geert Uytterhoeven
2014-02-04 20:39 ` H. Peter Anvin
2014-02-04 21:46 ` Geert Uytterhoeven
2014-02-04 21:47 ` H. Peter Anvin
2014-02-10 21:07 ` Jörn Engel
2014-02-04 20:31 ` Stephan Mueller
2014-02-04 21:34 ` H. Peter Anvin
2014-02-04 21:43 ` Geert Uytterhoeven
2014-02-04 20:25 ` Stephan Mueller
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=2039634.jSmQAS6tdi@myon.chronox.de \
--to=smueller@chronox.de \
--cc=andrewmcgr@gmail.com \
--cc=blogic@openwrt.org \
--cc=dave.taht@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hpa@zytor.com \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=sandyinchina@gmail.com \
--cc=tg@mirbsd.de \
--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
Powered by JetHome