Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Jun 2016 10:46:39 -0700
From: Kees Cook <>
To: "" <>
Subject: Re: Initialising random(4)

On Thu, Jun 16, 2016 at 10:31 AM, Sandy Harris <> wrote:
> On Thu, Jun 16, 2016 at 1:10 PM, Kees Cook <> wrote:
>> On Thu, Jun 16, 2016 at 10:06 AM, Sandy Harris <> wrote:
>>> The gresecurity patches include code to initiailse the driver's pools
>>> with random data. I have different code to accomplish the same task &
>>> think anyone planning to integrate that part of the gre stuff into the
>>> kernel should also have a look at mine:
>>> I submitted an earlier version as a kernel patch, part of a large &
>>> complex series of proposed patches.
>> Do you have a URL to the kernel patch you sent?
> Create the program to initialise things:
> Changes to the driver to use it:

Okay, thanks for the pointers. Yeah, this looks similar to what
latent_entropy does.

>> Right now, the
>> latent_entropy plugin does some static initialization with build-time
>> randomness, and then augments the pool with additional entropy during
>> boot. How does yours differ?
> Mine initialises all pools at compile time, using data from
> /dev/urandom on the development machine

Cool. Based on my quick examination, I think the latent_entropy way of
doing this is no less secure but is much easier to implement (it's
just an attribute addition in the code). It looks like your version
ends up with a lot of #ifdefs, etc, and targets a single collection of

I'm open to ways these two methods could work together, of course!



Kees Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.