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]

Date:	Tue, 4 Feb 2014 22:43:34 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>, "Theodore Ts'o" <tytso@....edu>,
	Jörn Engel <joern@...fs.org>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Dave Taht <dave.taht@...il.com>,
	John Crispin <blogic@...nwrt.org>,
	Andrew McGregor <andrewmcgr@...il.com>,
	Thorsten Glaser <tg@...bsd.de>, sandyinchina@...il.com
Subject: Re: [RFC PATCH 0/5] CPU Jitter RNG

On Tue, Feb 4, 2014 at 9:31 PM, Stephan Mueller <smueller@...onox.de> wrote:
>>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?

CPU, cache, and memory bus clocks are usually derived from the same
crystal. Hence they're not independent.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/