linux-kernel - Re: [RFC PATCH v1 42/50] drivers/ininiband: Use get_random

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200329163156.GB4675@SDF.ORG>
Date:   Sun, 29 Mar 2020 16:31:56 +0000
From:   George Spelvin <lkml@....ORG>
To:     Jason Gunthorpe <jgg@...pe.ca>, tytso@....edu
Cc:     linux-kernel@...r.kernel.org, Doug Ledford <dledford@...hat.com>,
        linux-rdma@...r.kernel.org, Faisal Latif <faisal.latif@...el.com>,
        Shiraz Saleem <shiraz.saleem@...el.com>,
        Bart Van Assche <bvanassche@....org>,
        Bernard Metzler <bmt@...ich.ibm.com>, lkml@....org
Subject: Re: [RFC PATCH v1 42/50] drivers/ininiband: Use get_random_u32()

On Sun, Mar 29, 2020 at 11:36:21AM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 21, 2019 at 08:21:45PM -0400, George Spelvin wrote:
>> There's no need to get_random_bytes() into a temporary buffer.
>> 
>> This is not a no-brainer change; get_random_u32() has slightly weaker
>> security guarantees, but code like this is the classic example of when
>> it's appropriate: the random value is stored in the kernel for as long
>> as it's valuable.
> 
> The mechanical transformation looks OK, but can someone who knows the
> RNG confirm this statement?

You might find commit 92e507d21613 ("random: document get_random_int() 
family") informative.

> Many of these places are being used in network related contexts, I
> suspect the value here is often less about secrecy, more about
> unguessability.

The significant difference is backtrackability.  Each get_random_bytes()
call has a final anti-backtracking step, to ensure that the random number
just generated cannot be recovered from the subsequent kernel state.
This is appropriate for encryption keys or asymmetric keys.

The get_random_{int,long,u32,u64} functions omit this step, which means
they only need one ChaCha20 crypto operation per 64 bytes of output,
not a minimum of one per call.

One good way of distinguishing the cases is to look for calls to 
memzero_explicit().  If you need to ensure the random bytes are securely 
destroyed, you need antibacktracking.  If your application doesn't care if 
anyone learns your session authentication keys after the session has been 
closed, you don't need it.