On Fri, Aug 23, 2013 at 12:54 AM, Patrick Pelletier
<c...@funwithsoftware.org> wrote:
>
> On 8/22/13 9:40 AM, Nico Williams wrote:
>
>> My suggestion is /dev/urandomN where N is one of 128, 192, or 256, and
>> represents the minimum entropy estimate of HW RNG inputs to date to
>> /dev/urandomN's pool. If the pool hasn't received that much entropy
>> at read(2) time, then block, else never block and just keep stretching
>> that entropy and accepting new entropy as necessary.
>
>
> That sounds like the perfect interface! The existing dichotomy between random
> and urandom (on Linux) is horrible, and it's nice to be able to specify how
> much entropy you are in need of.
Instead of a bunch of additional devices in /dev, the could add support
to use fcntl(2) and ioctl(2) system calls to control it. That would allow for
more granular control (although not be as convenient from languages
where fcntl and ioctl are not supported such as the shell or Java. On
second thought, scrap that idea. Of course, as far as blocking / non-blocking
I/O, one should be able to change that behavior by a flag to the open(2)
system call; e.g.,
int fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
or for /dev/urandom,
int fd = open("/dev/urandom", O_RDONLY | ~O_NONBLOCK);
At least that much could be supported from Java if not from the shell.
Then if it is opened not to block, any read(2) request should either
return whatever is available or -1 with errno set to EWOULDBLOCK
when the normal result would be to block because there is not sufficient
entropy. It would be up to the application to repeat the read() attempt
(hopefully sleeping awhile in between) if they haven't read enough
bytes.
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents." -- Nathaniel Borenstein
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
