From: Stephan Mueller <smueller@chronox.de>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Sandy Harris <sandyinchina@gmail.com>,
LKML <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: Sat, 12 Oct 2013 21:04:35 +0200 [thread overview]
Message-ID: <1868914.MfDRAbAfK8@tauon> (raw)
In-Reply-To: <20131012032835.GC30680@thunk.org>
Am Freitag, 11. Oktober 2013, 23:28:35 schrieb Theodore Ts'o:
Hi Theodore,
>Hi Stephan,
>
>I haven't had a chance to look at your paper in detail, yet, but a
>quick scan has found a huge red flag for me that puts the rest of your
>analysis in severe doubt for me.
>
>You say that you got really good results and perfect statistical
>entropy on a number of platforms, including on an MIPS embedded
>system. You also say that you are harvesting jitter by using
>get_cycles() yes?
>
>Well, on the MIPS platform, here is the definition of get_cycles:
>
>static inline cycles_t get_cycles(void)
>{
> return 0;
>}
There are multiple catches to this issue:
- First, if the time gathering function does not work or is to coarse,
the function jent_entropy_init() returns an error. As outlined in
jitterentropy(3), the result of this function must be honored before
using the RNG.
- Second, the time stamp function of jent_get_nstime uses
__getnstimeofday in case get_cycles returns zero (see implementation of
jent_get_nstime()). On MIPS systems with missing get_cycles, the RNG
would use the __getnstimeofday() as get_cycles returns 0. When using the
RNG in user space, it calls clock_gettime(CLOCK_REALTIME) that is backed
by the same timer of__getnstimeofday on MIPS.
Please consider the use of the jent_entropy_init function in the two
patches for /dev/random and kernel crypto API:
/dev/random:
+ /* we are uninitialized, try to initialize */
+ if(jent_entropy_init())
+ {
+ /* there is no CPU Jitter, disable the entropy
collector */
+ r->jent_enable = 0;
+ return;
+ }
kernel crypto API:
static int __init jent_drng_init(void)
{
...
ret = jent_entropy_init();
if(ret)
{
printk(DRIVER_NAME ": Initialization failed with host
not compliant with requirements: %d\n", ret);
return -EFAULT;
}
>
>So if you are getting great entropy results when in effect you
>couldn't possibly be harvesting any jitter at all, then something is
>really, Really, REALLY wrong with your tests.
>
>One might be that you are just getting great statistical results
>because of the whitening step. This is why I have very little faith
There is *no* whitening function (cryptographic or otherwise) involved
in the generation of random data. All is done by harvesting time deltas
and align them appropriately. This is the sole reason why the heart of
the RNG is only 30 lines of code.
I have added arguments about broken time stamp collections in section
4.3 of the documentation in [2]. These anti tests clearly show that
broken time stamps would be immediately visible and not disguised by
some whitening function.
Note, the testing of the 200+ systems is tone by measuring the jitter of
the core of the RNG. The measurement is logically similar to measure the
different add_*_randomness functions for random.c. Thus, even the logic
to arrange the timing values to a random value bit stream does not
affect the measurements.
>in statistical tests of randomness, given that they will return
>perfect results for the following "random number generator"
>
> AES_ENCRYPT(i++, NSA_KEY)
>
>Regards,
>
> - Ted
Ciao
Stephan
next prev parent reply other threads:[~2013-10-12 19:04 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 [this message]
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
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=1868914.MfDRAbAfK8@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).