linux-kernel - Re: is "premature next" a real world rng concern, or just an academic exercise?

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:   Tue, 10 May 2022 22:09:04 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     dodis@...nyu.edu, tytso@....edu, nadiah@...ucsd.edu,
        noahsd@...il.com, tessaro@...washington.edu,
        torvalds@...ux-foundation.org, jeanphilippe.aumasson@...il.com,
        jann@...jh.net, keescook@...omium.org, gregkh@...uxfoundation.org,
        peter@...ptojedi.org, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org, "D. J. Bernstein" <djb@...yp.to>
Subject: Re: is "premature next" a real world rng concern, or just an
 academic exercise?

Hey Dan,

On Tue, May 10, 2022 at 08:51:23PM +0200, D. J. Bernstein wrote:
> Jason A. Donenfeld writes:
> > Right, VMs are super problematic, but for that, there's now this
> > "vmgenid" driver, where the hypervisor actually gives a 128-bit seed to
> > guests when they're resumed, so that we can immediately reseed, which
> > should pretty comprehensively handle that situation.
> 
> Hmmm. If an application initializes its own RNG state from /dev/urandom,
> and is then cloned, and then generates an ECDSA nonce from the RNG
> state, and then uses this nonce to sign a message that's different
> across the clones, how is disaster averted?

Currently WireGuard will drop its ephemeral session key material from
the tx path, to prevent nonce use. This is because of an in-kernel
mechanism I added in 5.18, which is pretty minimal and non-invasive, and
came basically for free. CTRL+F for "vmgenid" in here for details:
https://www.zx2c4.com/projects/linux-rng-5.17-5.18/

For 5.19 (or at this point, more likely 5.20), there's a userspace
notifier in store, maybe, if I can figure out how to do it right.
There's a pretty bikesheddy thread here on what shape that interface
should take: https://lore.kernel.org/lkml/YnA5CUJKvqmXJxf2@zx2c4.com/
But basically there are some details about how an async interface should
work, and what the virtual hardware future, if any, looks like for a
memory mapped race-free polling interface. Plus some considerations on
how much we should care etc.

> Given the goal of sending money to cryptographers, I'm pretty sure we
> want the answer to be a security-audit nightmare, so let me suggest the
> following idea. There's SIGWINCH to notify processes about window-size
> changes, so there should also be a signal for RNG changes, which should
> be called SIGRINCH, and there should be a different mechanism to address
> RNG output cloning inside the kernel, and there should be endless papers
> on Grinch Attacks, including papers that sort of prove security against
> Grinch Attacks, and deployment of software that's sort of protected
> against Grinch Attacks, and fear of the bad PR from abandoning anything
> labeled as protection, because, hey, _maybe_ the protection accomplishes
> something, and it's not as if anyone is going to be blamed for whatever
> damage is caused by the systems-level effect of the added complexity.

I mean... you kid, but you're also kind of on point here. There are
about a thousand ways of doing this kind of notification that lead to
impossible-to-program-for paradigms that people will find necessary to
implement, and it'll be a nightmare if not done in a sufficiently slick
way. For the in-kernel thing WireGuard uses, it doesn't really matter
because the kernel is one big codebase so ergonomics can change need be.
But userspace is another challenge.

Jason