Nikos Mavrogiannopoulos wrote: > On Mon, 2016-04-25 at 11:46 -0400, George Spelvin wrote: >> 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 original (removed by your patch) line was: -high quality randomness such as one-time pad or key generation. It's not the words "one-time pad" I'm attached to, but the specific examples of when "high-quality randomness" is required. A big point is to teach people *how* to use it, and without those examples, when would anyone think "my application wants low-quality randomness"? You're right that a one-time pad is impractical, but it's still a common and familiar pedagogical example, and more importantly something that a person wondering which to use can see that their application is NOT. Your proposed patch *also* deleted the other usage example at the end: -should be used for everything except long-lived GPG/SSL/SSH keys. which really reduces the value of the man page as a guide to people who aren't crypto experts. >> 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. H'm... observation definitely trumps theoretical predictions based on reading the code. Is that a documentation problem or a code bug, or something I'm not understanding properly? If you look for that symbol in the source it definitely looks like it's supposed to wait for initial seeding. And ssh-keygen uses /dev/urandom. The getrandom(2) man page also documents the block-on-startup behavior. The driver wakes up the sleeping readers *before* printing the message. Is it possible that syslog is just losing the race? >> 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? To replace the text -If there is not sufficient entropy, a pseudorandom number generator is used -to create the requested bytes. or +If the estimated fresh entropy is not sufficient, a pseudorandom number generator is +used to create the requested bytes. with something that doesn't imply a mode switch. I labelled it "draft" because I wasn't really thrilled with the wording, myself, but I thought it gave the general idea and wasn't worth massaging into editorial perfection since it was due to get torn apart anyway. Can you think of better wording? I'm all for keeping it simple, but not at the expense of seriously misleading people. > 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. A reorganization might indeed be a good way forward; I was examining your changes without stepping back and considering the whole forest. Shall I take a stab at it? >> 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." 1. You have a buggy man page. The corrected one says "If the pool has not yet been initialized, then the call blocks, unless GRND_NONBLOCK is specified in flags." 2. I stand by what I wrote above. Without the GRND_RANDOM flag, getrandom() access the nonblocking pool (/dev/urandom). >> 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. No, it's not being ignored. The advice isn't "use /dev/random for SSH keys", but "*don't* use /dev/random for anything *except* SSH keys". The "(and maybe not even then)" part is implicit, but much less of a concern. The audience is not the authors of ssh, libssl, or gnupg; they know what they're doing. The audience is everyone *else*, and I think specific examples really help there. -- 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
