linux-kernel - Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 10 Feb 2013 20:32:37 +0100
From:	Stephan Mueller <smueller@...onox.de>
To:	Theodore Ts'o <tytso@....edu>, Jeff Epler <jepler@...ythonic.net>,
	linux-crypto@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On 10.02.2013 19:50:02, +0100, Theodore Ts'o <tytso@....edu> wrote:

Hi Ted,
> On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote:
>> However, the CPU has timing jitter in the execution of instruction. And
>> I try to harvest that jitter. The good thing is that this jitter is
>> always present and can be harvested on demand.
> How do you know, though, that this is what you are harvesting?

...

Given all your doubts on the high-precision timer, how can you
reasonably state that the Linux kernel RNG is good then?

The data from add_timer_randomness the kernel feeds into the input_pool
is a concatenation of the event value, the jiffies and the get_cycles()
value. The events hardly contains any entropy, the jiffies a little bit
due to the coarse resolution of 250 or 1000 Hz. Only the processor
cycles value provides real entropy.

Now you start doubting that with arguments that the resolution of that
processor cycle timer is very coarse. If this is the case, why shall I
trust random.c, especially considering the measurements observable
events like key strokes, mouse movements, interrupts (network cards).
Only if you have a high-precision time stamp, entropy can be derived
from these events.

Moreover, I cannot understand your comments on VMs -- on x86, the timer
depends on the rdtsc instruction which should be available on current
CPUs and is callable from user space. Hence, there should be no obstacle
to use this instruction within a VM and get a good reading.

Note, I will make measurements about the distribution of the timer
values and will come back to you.

Thanks
Stephan

-- 
| Cui bono? |

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