Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <YmlMGx6+uigkGiZ0@zx2c4.com>
In-Reply-To: <YmlMGx6+uigkGiZ0@zx2c4.com>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Sat, 30 Apr 2022 10:08:30 +0800
Message-ID: <CACXcFmnnS2HPoju3aTd29Nef0BLr9juS6SM4tGsTGe2eNsOyMA@mail.gmail.com>
Subject: Re: is "premature next" a real world rng concern, or just an academic exercise?
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     nadiah@cs.ucsd.edu, noahsd@gmail.com, dodis@cs.nyu.edu,
        tessaro@cs.washington.edu,
        Linus Torvalds <torvalds@linux-foundation.org>, djb@cr.yp.to,
        "Ted Ts'o" <tytso@mit.edu>,
        Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>,
        Jann Horn <jann@thejh.net>, Kees Cook <keescook@chromium.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        peter@cryptojedi.org,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> The Linux kernel RNG currently pretends to care about the "premature
> next" RNG threat model. I'm wondering whether this is sensible and
> corresponds to anything real.
>
> "Premature next" is the scenario in which:
> - Attacker compromises the current state of a fully initialized RNG with
>   a wild 'n crazy kernel infoleak.
> - New bits of entropy are added directly to the key used to generate the
>   /dev/urandom stream, without any buffering or pooling.

So don't do that, then. Keep a separate input pool/buffer and put
only hashed outputs from ir into the output pool.

> - Attacker then, somehow having read access to /dev/urandom, samples RNG
>   output and brute forces the individual new bits that were added.
> - Result: the RNG never "recovers" from the initial compromise, a
>   so-called violation of what academics term "post-compromise security".

Use chunks big enough for "catastrophic reseeding", impractical to
brute force, at least 64 bits & preferably larger.

>  Fortuna requires non-zero code
> complexity; does the benefit outweigh the cost of such complexity?

I'd say certainly not.

> The questions are thus:
> ...
> 3) More broadly speaking, what kernel infoleak is actually acceptable to
>    the degree that anybody would feel okay in the first place about the
>    system continuing to run after it's been compromised?

If we have a good entropy source -- e.g. running on an Intel CPU
& consider their RNG instruction trustworthy, or in a VM & trust
the host -- then we should be able to guarantee recovery at the
next reseeding. Just dump at least 128 bits from that source
into the input pool before hashing.

The interesting question is whether & how soon we can guarantee
recovery if no such source is available, we rely only on entropy
gathering from interrupts, with or without the gcc latent entropy
plugin.

> Is "premature next" just an academic exercise, rather than a real world
> RNG concern?

No.