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@xxxxxxxxx/ 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
