linux-kernel - Re: [RFC PATCH 0/5] CPU Jitter RNG

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]

Message-ID: <1874855.zG4mP2DzbB@tauon>
Date:	Tue, 04 Feb 2014 21:31:59 +0100
From:	Stephan Mueller <smueller@...onox.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Theodore Ts'o <tytso@....edu>,
	Jörn Engel <joern@...fs.org>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	macro@...ux-mips.org, ralf@...ux-mips.org, dave.taht@...il.com,
	blogic@...nwrt.org, andrewmcgr@...il.com, geert@...ux-m68k.org,
	tg@...bsd.de, sandyinchina@...il.com
Subject: Re: [RFC PATCH 0/5] CPU Jitter RNG

Am Dienstag, 4. Februar 2014, 11:06:04 schrieb H. Peter Anvin:

Hi Peter,

>On 02/04/2014 09:08 AM, Theodore Ts'o wrote:
>> I really wish we could get someone inside Intel who has deep
>> knowledge
>> about CPU internals to render an opinion about this.  My reaction to
>> "I can't explain where the entropy is coming from" seems very similar
>> to what my home grown attempts to create an encryption algoritm when
>> I
>> was much younger and much more foolish --- "it must be secure because
>> I can't break it".
>
>I think I have deep enough knowledge about CPU architectures in general
>(as opposed to specific Intel designs, which I wouldn't be able to
>comment on anyway) to comment.  The more modern and high performance a
>design you have the more sources of unpredictability there are.
>However, there are very few, if any, (unintentional) sources of actual
>quantum noise in a synchronous CPU, which means that this is at its
>core a PRNG albeit with a large and rather obfuscated state space.
>
>The quantum noise sources there are in a system are generally two
>independent clocks running against each other.  However, independent
>clocks are rare; instead, most clocks are in fact slaved against each
>other using PLLs and similar structures.  When mixing spread spectrum
>clocks and non-spread-spectrum clocks that relationship can be very
>complex, but at least for some designs it is still at its core
>predictable.

But isn't there an additional clock? The clock used to drive the cache 
and memory bus? When measuring memory accesses timings, larger 
variations in the execution time are evident. This also applies when 
hitting the caches (for L1, the variations are less than for L2 than for 
L3). The variations in access timings would come from the CPU wait 
states and their duration, would it not?

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/