On Fri, May 01, 2020 at 07:19:09PM +0000, Taylor R Campbell wrote: > +.It Dv GRND_INSECURE > +Do not block; instead fill > +.Fa buf > +with output derived from whatever is in the system entropy pool so > +far. > +Equivalent to reading from > +.Pa /dev/urandom ; > +see > +.Xr rnd 4 . > +.Pp > +If interrupted by a signal, may fail with > +.Er EINTR > +or return a short read. > +If successful, guaranteed to return at least 256 bytes even if > +interrupted. > +.Pp > +Despite the name, this is secure as long as you only do it > +.Em after > +at least one successful call without > +.Dv GRND_INSECURE , > +such as > +.Li "getrandom(..., 0)"
At which point calling with GRND_INSECURE is the same as calling with 0 ... > +or > +.Li "getrandom(..., GRND_RANDOM)" , > +or after reading at least one byte from > +.Pa /dev/random . Note that this is not the cases anymore on Linux. After reading 1 byte from /dev/random, /dev/urandom can still be unintialized, and so GRND_INSECURE is still insecure on Linux. > +.Pp > +.Sy WARNING : > +If you use > +.Dv GRND_INSECURE > +.Em before > +the system has full entropy. the output may enable an adversary to > +search the possible states of the entropy pool by brute force, and > +thereby reduce its entropy to zero. > +Thus, incautious use of > +.Dv GRND_INSECURE > +can ruin the security of the whole system. > +.It Dv GRND_RANDOM > +Block until the system entropy pool has full entropy; then generate a > +small amount of data. > +Equivalent to reading from > +.Pa /dev/random ; You might want to read https://lwn.net/Articles/808575/ The article states among other things that GRND_RANDOM is a noop, it behaves just like passing 0. Kurt