On Mon, 2016-04-25 at 11:46 -0400, George Spelvin wrote: > I like the bit about indeterminate delays. > > Removing the examples of high quality randomness I'm less fond of; > the whole idea is to inform people who don't quite understand what > the general terms mean. Good enough for one-time pads is a design > goal of /dev/random. If that's about documenting a design goal I'd prefer to move it out of the main text for 2 reasons. (a) There is no practical crypto system using one time pads, thus mentioning it in the main body only creates confusion (b), one time pad is such a theoretical construction that any real algorithm wouldn't implement it. > The whole language about "if not X. then a pseudorandom number > generator > is used" is actually pretty confusing now that I read it. It implies > some sort of mode switch which doen't exist. > > The bit about early boot is actually not as much of an issue as you > think. > Even /dev/urandom will stall early on boot until a minimum initial > seed > (128 bits at present) has been acumulated. (grep for > "urandom_init_wait") No it will not. We notice often the keys for sshd being generated *before* the kernel logs that the random pool has been initialized. > How about something more like (draft, not final edit): > > A read from the \fI/dev/urandom\fP device will not block > waiting for more entropy. > +If the estimated fresh entropy is not sufficient, a > \fI/dev/urandom\fP > +will produce output anyway, relying on the cryptographic primitives > in > +the driver's pseudo-random number generator to ensure that the > output, > +although correlated with previous output in an information theoretic > +sense (it exceeds the unicity distance), is secure for all practical > +purposes. What is the purpose of this text? To whom does it target? I wouldn't like to get into such details about the device in the manpage, but if you would like a section studying the theoretical properties of /dev/urandom I'd again suggest to keep it separate and elaborate. What is on the text above is certainly not complete analysis and is certainly not targetting administrators and developers who would like to understand what this device does. > I don't like the bit about "use /dev/random or getrandom(2)"; while > getrandom(2) should be mentioned in "see also", the equivalent is > "getrandom(..., GRND_RANDOM)". It's the flag, no the syscall. It is the syscall. According the description in getrandom(2): "If the pool has not yet been initialized, then the call blocks, unless GRND_RANDOM is specified in flags." > I strongly dislike the deletion of the "as a general rule" advice. > Specific recommendations are very valuable. This advice despite being present for so long, is widely ignored as /dev/urandom is used unconditionally by all software generating keys (SSH/SSL), gnupg being the exception. regards, Nikos -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
