linux-kernel - Re: [PATCH AUTOSEL 5.17 16/43] random: use computational hash for entropy extraction

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]

Date:   Wed, 30 Mar 2022 15:01:31 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Michael Brooks <m@...etwater.ai>
Cc:     David Laight <David.Laight@...lab.com>,
        Sasha Levin <sashal@...nel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Eric Biggers <ebiggers@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL 5.17 16/43] random: use computational hash for
 entropy extraction

On Wed, Mar 30, 2022 at 11:33:21AM -0700, Michael Brooks wrote:
> The /dev/random device driver need not concern itself with root
> adversaries as this type of user has permissions to read and overwrite
> memory - this user even possesses permission to replace the kernel elf
> binary with a copy of /dev/random that always returns the number 0 -
> that is their right.

The design consideration that random number generators do concern
themselves with is recovery after pool exposure.  This could happen
through any number of ways; maybe someone got a hold of the suspended
image after a hiberation, or maybe a VM is getting hybernated, and
then replicated, etc.

One can argue whether or not it's "reasonable" that these sorts of
attacks could happen, or whether they are equivalent to full root
access whether you can overwrite the pool.  The point remains that it
is *possible* to have situations where the internal state of the RNG
might have gotten exposed, and a design criteria is how quickly or
reliably can you reocver from that situation over time.

See the Yarrow paper and its discussion of iterative guessing attack
for an explanation of why cryptographers like John Kelsey, Bruce
Schneier, and Niels Ferguson think it is important.  And please don't
argue with me on this point while discussing which patches should be
backported to stable kernels --- argue with them.  :-)

Cheers,

						- Ted