linux-kernel - Re: Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

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:   Wed, 5 Jul 2017 09:16:09 -0400
From:   Paul Koning <paulkoning@...cast.net>
To:     open-iscsi@...glegroups.com
Cc:     Lee Duncan <lduncan@...e.com>, David Miller <davem@...emloft.net>,
        Eric Biggers <ebiggers3@...il.com>,
        "Nicholas A.Bellinger" <nab@...ux-iscsi.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>, Ted Ts'o <tytso@....edu>,
        Chris Leech <cleech@...hat.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-kernel@...r.kernel.org, "Jason A.Donenfeld" <Jason@...c4.com>
Subject: Re: Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use


> On Jul 5, 2017, at 3:08 AM, Ulrich Windl <Ulrich.Windl@...uni-regensburg.de> wrote:
> 
>>>> Jeffrey Walton <noloader@...il.com> schrieb am 17.06.2017 um 16:23 in Nachricht
> <CAH8yC8nHX2r9cfQ0gNeJAUrgSfAS8V16dVHv35BRnLn-YprZCg@...l.gmail.com>:
> 
> [...]
>> But its not clear to me how to ensure uniqueness when its based on
>> randomness from the generators.
> 
> Even with a perfect random generator non-unique values are possible (that's why it's random). It's unlikely, but it can happen. The question is whether the probability of non-unique values from /dev/urandom is any higher than that for values read from /dev/random. One _might_ be able to predict the values from /dev/urandom.

In the implementations I know, /dev/random and /dev/urandom are the same driver, the only difference is that when you read from /dev/random there's a check for the current entropy level.

If you haven't fed enough entropy yet to the driver since startup, and you read /dev/urandom, you get a value that isn't sufficiently secure.  

If you have a properly constructed RNG, as soon as it's been fed enough entropy it is secure (at least for the next 2^64 bits or so).  The notion of "using up entropy" is not meaningful for a good generator.   See Bruce Schneier's "Yarrow" paper for the details.

	paul