linux-kernel - Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Oct 2013 15:00:31 +0100
From:	Stephan Mueller <smueller@...onox.de>
To:	Theodore Ts'o <tytso@....edu>
Cc:	sandy harris <sandyinchina@...il.com>,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

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.

Though, does anybody has an idea how to flush/disable branch prediction 
on x86 (short of using an ARM where I can disable the branch prediction 
unit with CP15)? That is the last unit that I do not have a handle on.

>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.

The reason why I suspect that oscillating effect is the following: I 
spoke with two different employees from the research departments of 
major chip vendors. They mentioned that they see the very same jitter in 
their measurements albeit they tried to get rid of it. So, when they 
cannot get rid of that, I guess we will not be able to lower or even 
eliminate the jitter significantly.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/