lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 16 Jan 2017 23:36:40 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Denys Vlasenko <vda.linux@...glemail.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...ux.intel.com>,
        Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: random: /dev/random often returns short reads

On Mon, Jan 16, 2017 at 07:50:55PM +0100, Denys Vlasenko wrote:
> 
> /dev/random can legitimately returns short reads
> when there is not enough entropy for the full request.

Yes, but callers of /dev/random should be able to handle short reads.
So it's a bug in the application as well.

You have correctly identified the correct commit which introduced the
problem, but it's been in the tree for three years with very few
people who are complaining.

As near as I can tell, the (few) people who are complaining are those
who are using Havegnd to add pretend history, and then are are
reconfiguring OpenSSL to use /dev/random, in an misguided attempt to
try to get FIPS certification, and for some reason it's ok to use
pretend entropy from Havegnd, and modify OpenSSL to use /dev/random,
but it's not OK to modify OpenSSL to retry short reads.

> The code looks like it effectively credits the pool only for ~3/4
> of the amount, i.e. 24 bytes, not 32.

How much it credits the pools varies depending on how many bits of
entropy are being transferred and how full the pool happens to be
beforehand.  Reversing the calculation so that we transfer exactly the
right number of bits is tricky, and if we transfer too many bits, we
risk "wasting" entropy bits.  Of course, it doesn't matter if we're
transfering pretend entropy only for the purposes of getting FIPS
certification, but getting it Right(tm) is non-trivial.

If someone wants to send me a patch, I'll happily take a look at it,m
but given that fixing userspace is something you really should do
anyway, it's not high on my priority list for me to try to look at and
fixing myself.

						- Ted

Powered by blists - more mailing lists