On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan <lduncan@xxxxxxxx> 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 <lduncan@xxxxxxxx> 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. 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. Jeff
