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
