linux-kernel - Re: [PATCH,RFC] random: collect cpu randomness

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:	Mon, 3 Feb 2014 10:50:42 -0500
From:	Jörn Engel <joern@...fs.org>
To:	Theodore Ts'o <tytso@....edu>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	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, smueller@...onox.de,
	geert@...ux-m68k.org, tg@...bsd.de
Subject: Re: [PATCH,RFC] random: collect cpu randomness

On Sun, 2 February 2014 15:36:17 -0500, Jörn Engel wrote:
> 
> Measuring the randomness from random_get_entropy() with above approach
> failed because there was so much randomness.  All numbers in all runs
> were different.  Taking the delta between the numbers, again almost all
> numbers were different with at most 1 identical delta per 1000.
> Compared to a high-precision clock, no other input comes within two
> orders of magnitude.

I think this is a key result from my tests.  The best source is a
timer (counter) that is both
a) high-resolution and
b) asynchronous to the measurement event.

If the measurement event is an interrupt and the CPU has a
cycle-counter, you are set.  On interesting systems lacking a
cycle-counter, we still have a high-resolution counter or sorts that
is the CPU itself.

Instruction pointer and stack pointer for both kernel and userland are
one way to read out the "counter".  Main problem here are tight loops
where your "counter" is not high-resolution at all.  But something
within the CPU is constantly changing.  And that something tends to be
contained in the registers.

How about taking the saved registers from the interrupted CPU, xor'ing
them all and calling the result random_get_entropy() on systems
lacking a good cycles-counter?

Jörn

--
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000
--
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/