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

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

[Paul Koning]

> On Jun 17, 2017, at 10:23 AM, Jeffrey Walton  wrote:
> 
> On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan  wrote:
>> On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote:
>>> Hi Lee,
>>> 
>>> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan  wrote:
 It seems like what you are doing is basically "good", i.e. if there is
 not enough random data, don't use it. But what happens in that case? The
 authentication fails? How does the user know to wait and try again?
>>> 
>>> The process just remains in interruptible (kill-able) sleep until
>>> there is enough entropy, so the process doesn't need to do anything.
>>> If the waiting is interrupted by a signal, it returns -ESYSRESTART,
>>> which follows the usual semantics of restartable syscalls.
>>> 
>> In your testing, how long might a process have to wait? Are we talking
>> seconds? Longer? What about timeouts?
>> 
>> Sorry, but your changing something that isn't exactly broken, so I just
>> want to be sure we're not introducing some regression, like clients
>> can't connect the first 5 minutes are a reboot.
> 
> CHAP (https://www.rfc-editor.org/rfc/rfc1994.txt) and iSCSI
> (https://www.ietf.org/rfc/rfc3720.txt) require random values. If iSCSI
> is operating without them, it seems like something is broken. From RFC
> 3720, Section 8.2.1, CHAP Considerations:
> 
>   When CHAP is performed over a non-encrypted channel, it is vulnerable
>   to an off-line dictionary attack.  Implementations MUST support use
>   of up to 128 bit random CHAP secrets, including the means to generate
>   such secrets and to accept them from an external generation source.
>   Implementations MUST NOT provide secret generation (or expansion)
>   means other than random generation.

That only applies to the generation of the secret, which is configured into 
iscsi, not created by it.  A utility to generate the secret might be supplied, 
of course, just as one might have utilities to generate strong passwords, but 
it's not a component of the iSCSI protocol.

> CHAP actually has a weaker requirement since it only requires _unique_
> (and not _random_). From RFC 1994, Section 2.3, Design Requirements:
> 
>   Each challenge value SHOULD be unique, since repetition of a
>   challenge value in conjunction with the same secret would permit an
>   attacker to reply with a previously intercepted response.  Since it
>   is expected that the same secret MAY be used to authenticate with
>   servers in disparate geographic regions, the challenge SHOULD exhibit
>   global and temporal uniqueness.
> 
> But its not clear to me how to ensure uniqueness when its based on
> randomness from the generators.

A strong RNG of length n will produce numbers likely to be unique until you 
approach the birtday limit 2^(n/2).  So, say, a 128 bit challenge will be 
adequate.

paul