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

[Theodore Ts'o]

On Wed, Jul 05, 2017 at 09:03:43AM +0200, Ulrich Windl wrote:
> > Note, during the development of my /dev/random implementation, I added the 
> > getrandom-like blocking behavior to /dev/urandom (which is the equivalent to
> > Jason's patch except that it applies to user space). The boot process locked
> 
> I thought reads from urandom never block by definition. An older manual page
> (man urandom) also says: "A  read  from  the  /dev/urandom device will not
> block waiting for more entropy."

As I said in my original message, I *tried* this as an experiment.
Because lots of security-obsessed people were disputing my
intelligence, my judgement, and in some cases, my paternity becuase I
wouldn't change /dev/urandom not to block.

So I did the experiment so I could give them hard data about why we
couldn't go down that path.

> > up since systemd wanted data from /dev/urandom while it processed the 
> > initramfs. As it did not get any, the boot process did not commence that 
> > could 
> > deliver new events to be picked up by the RNG.

And indeed, making this change brick'ed at least one version of Ubuntu
and one version of CeroWRT, as reported by the kernel's 0-day testing
system.  As a result, this patch (which was always a proof of concept,
not anything I thought had any chance of going upstream), was dropped.

Since in the kernel, We Do Not Break Backwards Compatibility, this is
why we have a new interface --- getrandom(2) --- instead of changing
an existing interface.  (Well, there were multiple good reasons for
getrandom, but this was definitely one of them.)

- Ted

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

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

[Theodore Ts'o]

On Wed, Jul 05, 2017 at 09:16:09AM -0400, Paul Koning wrote:
> 
> 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.

It's in the same driver but /dev/random and /dev/urandom are different
beasts.  Pre-4.9 we use the same SHA-1 based generator, but we use
different state pools, and we periodically "catastrophically reseed"
(ala Yarrow) from the random pool to the urandom pool.  Getrandom(2)
uses the urandom pool.

In 4.9 and later kernels, /dev/urandom and getrandom(2) use a ChaCha20
based generator which provides for more speed.  We still use the SHA-1
pool for the random pool because it allows for a much larger "state
pool" to store entropy.

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

A lot of this depends on whether or not you trust your crypto
primitives or not.  The /dev/random driver was the very first OS-based
random generator, and back then, export restrictions were still a
thing (which is why we only used MD5 and SHA-1 as crypto primitives),
and our cryptoanalytic understanding of what makes for a good crypto
hash or encryption algorithm was quite limited.  So trying to
accumulate a large amount of entropy pool of entropy is a good thing,
because even if there was a minor weakness in the crypto hash (and for
a while we were using MD5), relying on the adversary not being able to
guess all of the environmental noise harvested by the kernel would
cover for a lot of sins.

Remember, in the kernel we have access to a large amount of
environmental noise, so it makes a lot of sense to take advantage of
that as much as possible.  So by having a huge state pool for the
/dev/random entropy pool, we can harvest and store as much of that
environmental noise as possible.  This buys us a large amount of
safety margin, which is good thing because somewhere there might be
some Linux 2.0 or Linux 2.2 based router sitting in someone's home
where /dev/random is using MD5.  Those ancient kernels are probably
riddled with zero-day security holes, but the safety margin of using a
large entropy pool is such that even though there are many known
attacks against MD5, I'm actually pretty confident that the large
state pool mitigates the weakness of MD5 as used by /dev/random and
/dev/urandom.  At the very least, it will be much easier for the NSA
to use some other zero-day to attack the said router with the ancient
kernel, well before they try to reverse engineer its /dev/urandom
output.  :-)

- Ted

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

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

[Ulrich Windl]

>>> Paul Koning  schrieb am 05.07.2017 um 15:16 in
Nachricht <8cc15605-cff3-4d6e-adbe-5efc9f8e7...@comcast.net>:

>> On Jul 5, 2017, at 3:08 AM, Ulrich Windl  
> wrote:
>> 
> Jeffrey Walton  schrieb am 17.06.2017 um 16:23 in 
> Nachricht
>> :
>> 
>> [...]
>>> 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.  

Seeing it as a blackbox, you never know when additional entropy will be fed in, 
so you MIGHT get a value that isn't sufficiently secure. Only if you are sure 
no entropy is fed into the pool, you are likely to guess the next value. I 
think only if you have observed a lot of values to deduce the internal state of 
the pool, however.

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

I don't know that paper (yet). But saying you only need a limited amount of 
"good entropy" and then a generator is secure surprises me from what I know so 
far.
An attacker knowing the algorithm is required to never detect the internal 
state of the generator (which is finite).

Regards,
Ulrich

> 
>   paul
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to open-iscsi+unsubscr...@googlegroups.com.
> To post to this group, send email to open-iscsi@googlegroups.com.
> Visit this group at https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Koning]

> On Jul 5, 2017, at 3:08 AM, Ulrich Windl  
> wrote:
> 
 Jeffrey Walton  schrieb am 17.06.2017 um 16:23 in 
 Nachricht
> :
> 
> [...]
>> 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

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.