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

["Jason A. Donenfeld" <Jason@zx2c4.com>]

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