On Fri, 2016-10-21 at 16:07 +0200, Stephan Mueller wrote: > > > -When read, the \fI/dev/random\fP device will return random bytes > > > -only within the estimated number of bits of noise in the entropy > > > -pool. > > > -\fI/dev/random\fP should be suitable for uses that need very > > > -high quality randomness such as one-time pad or key generation. > > > +When read, the \fI/dev/urandom\fP device return random bytes > > > using a > > > pseudorandom +number generator seeded from the entropy pool. That > > Starting with 4.8, there is no nonblocking_pool any more. Please > refer to the ChaCha20 DRNG. Hi Stephan, I am not sure the suggestion above is clear to me. The text above (nor the rest of the manpage) doesn't mention details about non- blocking/blocking pools. I intentionally left such details out as they do not provide information to a reader who is not familiar with the actual implementation behind it. The CHACHA20 DRNG is another detail that I wouldn't like the manpage to mention since it is a technical detail and may even change in the future (e.g., to a faster stream cipher). Nevertheless, I find this suggestion orthogonal to my text above. There may be another update of the manpage to add these details (even though I wouldn't really like it). > > +.LP > > > +The \fI/dev/random\fP device is a legacy interface which dates > > > back to > > > +a time where the cryptographic primitives used in the > > > implementation > > > +were not widely trusted. It will return random bytes > > > +only within the estimated number of bits of fresh noise in the > > > entropy > > > +pool, blocking if necessary. > > > +\fI/dev/random\fP is suitable for applications that need very > > > +high quality randomness, and can afford indeterminate delays. > > Would it be possible to add something around getrandom stating that > it blocks > until initially 128 bits of entropy are measured before it unblocks > and > behaves like /dev/urandom? Maybe it makes even sense to add a > recommendation > to use getrandom in favor of /dev/urandom? Note that this is the manpage on /dev/urandom and /dev/random only. getrandom() has a separate manpage which lists (or should list) such information. Said that, indeed this suggestion is right, but I think this recommendation is mildly already there (the quotes may hide it). It is on the 3rd paragraph: "When used during early boot time, this device may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead." 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
