linux-kernel - Re: random: /dev/random often returns short reads

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK1hOcMmmbt8SMBefbG265fp9OzoV47UH3j67EL06HnxbWoAkQ@mail.gmail.com>
Date:   Tue, 17 Jan 2017 09:21:31 +0100
From:   Denys Vlasenko <vda.linux@...glemail.com>
To:     "Theodore Ts'o" <tytso@....edu>,
        Denys Vlasenko <vda.linux@...glemail.com>,
        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 Tue, Jan 17, 2017 at 5:36 AM, Theodore Ts'o <tytso@....edu> wrote:
> 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.

I absolutely agree, whoever stumbled over it has a bug
in their app.

>> 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.

I think the problem is that even if the target pool has no entropy
at all, current algorithm thinks that transferring N random bytes
to it gives it N*3/4 bytes of randomness.

> 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,

Will something along these lines be accepted?

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -653,6 +653,9 @@ static void credit_entropy_bits(struct
entropy_store *r, int nbits)
        if (nfrac < 0) {
                /* Debit */
                entropy_count += nfrac;
+       } else if (entropy_count == 0) {
+               /* Credit, and the pool is empty */
+               entropy_count += nfrac;
        } else {
                /*
                 * Credit: we have to account for the possibility of
                 * overwriting already present entropy.  Even in the


> but given that fixing userspace is something you really should do
> anyway

I agree. It's just not in my (or my company's, IIUC) userspace code.
I wouldn't even know about this thing since *my* programs do handle
short reads correctly.