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: <52F15CF0.8080209@zytor.com>
Date:	Tue, 04 Feb 2014 13:34:40 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Stephan Mueller <smueller@...onox.de>
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

On 02/04/2014 12:31 PM, Stephan Mueller wrote:
>>
>> 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?
> 

Variations doesn't mean quantum unpredictable noise.  All the clocks you
are referring to are derived from the same BCLK and thus predictable.
What you have here is a PRNG with a large and obscure state space.

	-hpa


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