linux-kernel - Re: [RFC] Should writes to /dev/urandom immediately affect 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 21 Sep 2023 09:30:39 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Eric Biggers <ebiggers@...nel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Jann Horn <jannh@...gle.com>
Subject: Re: [RFC] Should writes to /dev/urandom immediately affect reads?

On Wed, Sep 20, 2023 at 01:48:55PM -0700, Linus Torvalds wrote:
> On Wed, 20 Sept 2023 at 13:45, Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > See my first email where I explained the problems with the current behavior.
> > Especially the third paragraph.
> 
> I really don't think that's the obvious way at all. Anybody who treats
> a seed file that way just doesn't care, and whipped up a (bad) shell
> script randomly.

The shell script (and documentation in the kernel man pages suggesting
the shell script) is basically historical, and obsolete.  It was
needed back when we weren't as aggressively seeding the RNG at boot
time, before we unified /dev/urandom and /dev/random.  These days, I
really don't think it matters all that much.

The main threat we've historically been concerned is badly designed
IOT devices (remember, the 'S' in IOT stands for security) which
generates a long-term cryptographic key within milliseconds of the
initial power-on, which led to such hillarious results as all HP
Printers publically on the Internet having one of 256 possible private
keys.  In those sorts of situations, there *was* no seed file, and
even if there were, it would be identical across all of the IOT's
initially imaged root file system.

I do have one slight concern about unconditionally reseeding whenever
there is a write to /dev/[u]random, whih is in the purely hypothetical
scenario mostly of interest to academics writing crypto papers, where
we assume the attacker has stolen the full internal state of the RNG,
if the attacker is constantly writing a small amount of known data to
/dev/random, and monitoring its output, it would be disabling the
"catastrophic reseed" part of the design, and so it might make it
easier for the attacker to maintain accurate knowledge of the internal
state of the RNG over long period of time.  So a perfectionist would
probably put a timeout where writing to /dev/urandom would result in a
reseed every N minutes or some such.

But honestly?  I'm not convinced it's worth it; devices/systems where
this matter are probably not getting security updates *anyway*, so the
much simpler way the NSA/KGB/MSS would attack the device is paying a
few thousand dollars for a zero-day, and breaking kernel security
that way.

Cheers,

						- Ted