linux-kernel - Re: [PATCH][RFC] CPU Jitter random number generator (resent)

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>] [day] [month] [year] [list]

Date:	Tue, 21 May 2013 18:56:04 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	Sandy Harris <sandyinchina@...il.com>
Cc:	linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] CPU Jitter random number generator (resent)

On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris <sandyinchina@...il.com> wrote:

Hi Sandy,

> I very much like the basic notion here. The existing random(4) driver
> may not get enough entropy in a VM or on a device like a Linux router
> and I think work such as yours or HAVEGE (
> http://www.irisa.fr/caps/projects/hipsor/) are important research. The
> paper by McGuire et al of "Analysis of inherent randomness of the
> Linux
> kernel" (http://lwn.net/images/conf/rtlws11/random-hardware.pdf)
> seems to show that this is a fine source of more entropy.
> 
> On the other hand, I am not certain you are doing it in the right
> place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/)
> put it in a demon that just feeds /dev/random, probably also not the
> right place. haveged(8) ( http://www.issihosts.com/haveged/) also
> puts it in a demon process. It may, as you suggest, belong in the
> kernel instead, but I think there are arguments both ways.

Thanks for your insights. What I propose is that it shall NOT have any
fixed place at all.

The entropy collection shall be as close to the "consumer" as
possible. There shall be NO single one entropy collector, but one for
every consumer.

That is the reason, why the code I am offering has that many links to
different crypto libs or even a stand-alone shared lib compilation.
Also, the implementation for the kernel crypto API should be used in a
way where one "consumer" instantiates the raw RNG or even the DRNGs
independently from others. That means, in-kernel users of entropy like
IPSEC shall instantiate the the kernel crypto API code independently
of others.
> 
> Could we keep random(4) mostly as is and rearrange your code to just
> give it more entropy? I think the large entropy pool in the existing
> driver is essential since we sometimes want to generate things like a
> 2 Kbit PGP key and it is not clear to me that your driver is entirely
> trustworthy under such stress.

We can easily do that -- the different links I provide to different
crypto libs can be extended by a patch to random(4) too. My goal is to
go away from a central source of entropy to a fully decentralized
source.

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