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]
Message-ID: <20220510185123.80607.qmail@cr.yp.to>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ