Le 10/11/2016 à 15:35, Nikos Mavrogiannopoulos a écrit : > On Thu, 2016-11-10 at 15:23 +0100, Michael Kerrisk (man-pages) wrote: >> [was: Re: Status for bug 71211? [random(4): clarify utility and >> volume]] >> >> Hello Nikos, >> >> On 11/10/2016 09:42 AM, Nikos Mavrogiannopoulos wrote: >>> >>> On Wed, 2016-11-09 at 16:27 +0100, Michael Kerrisk (man-pages) >>> wrote: >>>> >>>> Nikos, >>>> >>>> This was an earlier mail from Laurent Georget. I bring >>>> you into this thread in case there's any of Laurent's comments >>>> that may be helpful as inspiration for your patch. >>>> >>>> See also https://bugzilla.kernel.org/show_bug.cgi?id=71211 >>> >>> I think that's a nice comment. The text referred to applies to old >>> kernels not new ones (especially not after the recent rewrite), and >>> I >>> think it documents and opinion rather than a fact. I am inclined to >>> simply drop the referred paragraph. Any better suggestions? >> >> Dropping the paragraph appears too strong too me. Surely we want >> to maintain a recommendation not to consume too much data from >> /dev/urandom? > > Stephan Mueller or Ted should be able to provide more info for the new > code. I think in the new versions of /dev/urandom the amount consumed > shouldn't cause issues or affect other users. > > However, I agree that overall, that this is a low level interface and > it should be treated as such. I.e., I'd expect applications to use > their crypto libraries' interfaces rather than getrandom directly. The > reason is not only about being slow, but about having to take care > about EINTR, short reads, quirks such as for early boot, etc [0]. I agree. For non-cryptographic uses, it's always better to use a userspace random-number generator such as the generators provided by the standard library of Java, Python, etc. or by OpenSSL. For cryptographic purposes, check what available libraries have first, and if needs be, getrandom is fine for all reasonable usesand avoid the hassle of opening and closing /dev/urandom. The warning about the limits of /dev/urandom proposed in the other patch (about short reads and EINTR) seems sufficient to me. It's also already written that up to 256 bytes is always fine, more than 32MB at once is impossible. I don't think we need to stress out anything else. Cheers, Laurent > > regards, > Nikos > > [0]. I've tried to write down some argumentation at: > http://nmav.gnutls.org/2016/10/random-generator-linux.html >
Attachment:
signature.asc
Description: OpenPGP digital signature
