3 ms·

You missed the 3rd reason for this. Calls to /dev/urandom can not block, so it a script or program requests random bytes before entropy has been set up, it can

You missed the 3rd reason for this. Calls to /dev/urandom can not block, so it a script or program requests random bytes before entropy has been set up, it can get back bad random bytes. The new system call getrandoms does block, so early scripts will not get bad entropy data.

deleted 12y ago
[deleted]
kazinator 12y ago
The newly proposed system call, as implemented in the mailing list patch, provides the functionality of both random and urandom: the behaviors are distinguished by a bitmask. Take a look at the code. If the flag GRND_RANDOM is used, then it uses the random device, otherwise urandom. Independently of this, blocking behavior is requested with GRND_BLOCK. If this is omitted, then the random device bails with errno == EAGAIN if it doesn't have enough entropy, otherwise it blocks. If GRND_BLOCK is omitted with the urandom method (GRND_RANDOM is omitted), then it will bail with -EAGAIN if the urandom device is not initialized; otherwise it just calls urandom_read. With GRND_BLOCK, it will block for urandom to initialize, if necessary. The new system call only blocks when given GRND_BLOCK, and it uses urandom unless given the flag GRND_RANDOM. If it is given GRND_RANDOM, but not GRND_BLOCK, and not enough entropy is available, then the system call with bail with errno == EAGAIN. If there is no GRND_RANDOM then it falls back on urandom_read: that is usually non-blocking.
- Dylan16807 12y ago
  Sure, blocking is a flag. You're ignoring the point, which is that it will never return bad data.
  - kazinator 12y ago
    I see; if the point is that /dev/urandom doesn't even block when it is uninitialized, that is valid. This system call (when used to access urandom) will either block on urandom to be initialized, or else fail loudly with -EAGAIN, which is an improved interface.
leccine 12y ago
How do you know it is not random? http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/2000/300/2318/2318.strip.gif http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/...

deleted 12y ago

[deleted]

kazinator 12y ago

The newly proposed system call, as implemented in the mailing list patch, provides the functionality of both random and urandom: the behaviors are distinguished by a bitmask. Take a look at the code. If the flag GRND_RANDOM is used, then it uses the random device, otherwise urandom. Independently of this, blocking behavior is requested with GRND_BLOCK. If this is omitted, then the random device bails with errno == EAGAIN if it doesn't have enough entropy, otherwise it blocks. If GRND_BLOCK is omitted with the urandom method (GRND_RANDOM is omitted), then it will bail with -EAGAIN if the urandom device is not initialized; otherwise it just calls urandom_read. With GRND_BLOCK, it will block for urandom to initialize, if necessary. The new system call only blocks when given GRND_BLOCK, and it uses urandom unless given the flag GRND_RANDOM. If it is given GRND_RANDOM, but not GRND_BLOCK, and not enough entropy is available, then the system call with bail with errno == EAGAIN. If there is no GRND_RANDOM then it falls back on urandom_read: that is usually non-blocking.

Dylan16807 12y ago
Sure, blocking is a flag. You're ignoring the point, which is that it will never return bad data.
- kazinator 12y ago
  I see; if the point is that /dev/urandom doesn't even block when it is uninitialized, that is valid. This system call (when used to access urandom) will either block on urandom to be initialized, or else fail loudly with -EAGAIN, which is an improved interface.

leccine 12y ago

How do you know it is not random? http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/2000/300/2318/2318.strip.gif http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/...