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 20:51:23 +0200
From:   "D. J. Bernstein" <djb@...h.uic.edu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Yevgeniy Dodis <dodis@...nyu.edu>, tytso <tytso@....edu>,
        Nadia Heninger <nadiah@...ucsd.edu>,
        Noah Stephens-Dawidowitz <noahsd@...il.com>,
        Stefano Tessaro <tessaro@...washington.edu>,
        torvalds@...ux-foundation.org, jeanphilippe.aumasson@...il.com,
        jann@...jh.net, keescook@...omium.org, gregkh@...uxfoundation.org,
        Peter Schwabe <peter@...ptojedi.org>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: is "premature next" a real world rng concern, or just an
 academic exercise?

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.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)