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? 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. ---D. J. Bernstein P.S. Yes, yes, I know the name "Grinch Attack" has been used before.
Attachment:
signature.asc
Description: PGP signature
