Bug #129829 for Crypt-URandom: Uses buffered reads

Sat Jun 15 05:36:47 2019 geissert [...] debian.org - Ticket created

Subject:	Uses buffered reads
Date:	Sat, 15 Jun 2019 11:36:31 +0200
To:	bug-Crypt-URandom [...] rt.cpan.org
From:	Raphael Geissert <geissert [...] debian.org>

Hi, Crypt::URandom's use of FileHandle means the reads of /dev/urandom are buffered, but this is not documented. A quick look with strace: openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 3 read(3, "\247ws\30\352\\\274\212]-\305?`\221\232qi\303\333O\304-\310\0\303o\314\2667\250.h"..., 8192) = 8192 So 8192 bytes were read for a code that only asked for 10 bytes of the urandom PRNG. It would be great if the reads were not buffered, but documenting the behaviour should be the least that could be done. Thanks in advance! Cheers, -- Raphael Geissert - Debian Developer www.debian.org

Wed Jun 19 17:01:45 2019 DDICK [...] cpan.org - Taken

Wed Jun 19 17:08:27 2019 DDICK [...] cpan.org - Correspondence added

On Sat Jun 15 19:36:47 2019, geissert@debian.org wrote: Show quoted text

> So 8192 bytes were read for a code that only asked for 10 bytes of the > urandom PRNG.

Yup, that's interesting behaviour. If the code was reading from /dev/random, it would be a killer, but reading extra bytes from /dev/urandom doesn't seem to effect the amount of entropy in the system according to /proc/sys/kernel/random/entropy_avail. Is the concern a performance issue or a randomness issue or something else? Show quoted text

> It would be great if the reads were not buffered, but documenting the > behaviour should be the least that could be done.

Definitely agreed that the behaviour should be documented. I don't think it's a good idea to change the API after such a long time, but thinking about maybe either adding a new non-buffering function or parameter to the existing function to specify non-buffering reads if required. Thanks for the report.

Wed Jun 19 17:08:28 2019 The RT System itself - Status changed from 'new' to 'open'

Thu Jun 20 08:06:12 2019 geissert [...] debian.org - Correspondence added

Subject:	Re: [rt.cpan.org #129829] Uses buffered reads
Date:	Thu, 20 Jun 2019 14:05:50 +0200
To:	bug-Crypt-URandom [...] rt.cpan.org
From:	Raphael Geissert <geissert [...] debian.org>

Hi, On Wed, 19 Jun 2019, 23:08 David Dick via RT, <bug-Crypt-URandom@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=129829 > > > On Sat Jun 15 19:36:47 2019, geissert@debian.org wrote:

> > So 8192 bytes were read for a code that only asked for 10 bytes of the > > urandom PRNG.

> > Yup, that's interesting behaviour. If the code was reading from > /dev/random, it would be a killer, but reading extra bytes from > /dev/urandom doesn't seem to effect the amount of entropy in the system > according to /proc/sys/kernel/random/entropy_avail. Is the concern a > performance issue or a randomness issue or something else? >

The effect on the entropy estimate depends on the kernel version. In any case it's best to only consume what's needed. E.g. if Crypt::URandom was used during an entropy starvation condition like at boot time the dubious quality of the CSPRNG would last beyond the condition itself. Show quoted text

> Definitely agreed that the behaviour should be documented. I don't think > it's a good idea to change the API after such a long time, but thinking > about maybe either adding a new non-buffering function or parameter to the > existing function to specify non-buffering reads if required. >

Yes, that sounds like a great compromise!

Tue Aug 20 11:52:23 2019 shawnw.mobile [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #129829] Uses buffered reads
Date:	Tue, 20 Aug 2019 08:52:02 -0700
To:	bug-crypt-urandom [...] rt.cpan.org
From:	Shawn Wagner <shawnw.mobile [...] gmail.com>

Using sysread instead of read will only read the requested number of bytes without any buffering. Doesn't require any API changes.