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]

Message-ID: <CAOnCY6QUx-A5Cp+HXeOyHa5oBFq5zWmcJOg_yH3Ty20-13Xbcw@mail.gmail.com>
Date:   Wed, 30 Mar 2022 12:08:44 -0700
From:   Michael Brooks <m@...etwater.ai>
To:     "Theodore Y. Ts'o" <tytso@....edu>
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>,
        nicholas Lyons <nicholas@...eytyp.com>
Subject: Re: [PATCH AUTOSEL 5.17 16/43] random: use computational hash for
 entropy extraction

Good point Ted, I agree we should have a defense-in-depth design that
plans on failure. I expect keypoolrandom to be resistant against this
attack as well.

In this threat model, p' is a Laplacian Demon. Any parallel
construction is aided by whatever source of information the attacker
can come by.  Using jiffies as a known-perimage aids Laplace's Demon,
as does a memory disclosure vulnerability.  Leplace's Demon can simply
"get lucky" and report both false-positives and false-negatives, but
in this model it should get more lucky over time.  Now we get into the
realm of statistics and predictive mathematics, which gets into
Langevin Dynamics and Einstein's early work describing Brownian
Motion.

Looping in a fellow Cryptographer Nicholas, who has a passion for
Laplace's work.

Regards,
Michael

On Wed, Mar 30, 2022 at 12:01 PM Theodore Y. Ts'o <tytso@....edu> wrote:
>
> 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