From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F053E3858027; Mon, 8 Aug 2022 12:29:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F053E3858027 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/29437] arc4random is too slow Date: Mon, 08 Aug 2022 12:29:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2022 12:29:32 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29437 Adhemerval Zanella changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adhemerval.zanella at lina= ro dot o | |rg --- Comment #6 from Adhemerval Zanella --- (In reply to Miroslav Lichvar from comment #5) > I need a PRNG that is fast and not as easily predictable as random(). Tha= t's > how arc4random() is documented on FreeBSD and other systems supported by > chrony. As I understand it, it's not supposed to be used to generate > long-term keys, for instance. Both OpenBSD (and FreeBSD which base its implementation on OpenBSD) [1] and MacOS [2] (which used to be based on OpenBSD, but now has its own implementation) state they are CSRNG (OpenBSD doc is not really clear in the sentence it describes some of the internal, but it is used as CSRNG in the code). However, the OpenBSD implementation (and all implementations based on the user-managed buffer, like FreeBSDB and libbsd) uses heuristics to trigger t= he buffer reseed, which is not *suffice*.=20 For example, when a virtual machine is forked, restored, or duplicated, it's imperative that the RNG doesn't generate the same outputs. For this reason, there's a small protocol between hypervisors and the kernel that indicates = this has happened, alongside some ID, which the RNG uses to reseed immediately, = so as not to return the same numbers. So the kernel becomes the focal point on how to correctly generate and mana= ge cryptographic secure RNG, and one of the drives of arc4random inclusion is = it should not provide worse RNG than getrandom syscall. >=20 > If the reason for adding arc4random() was source compatibility, that won't > work well for applications that need high performance. They will still ne= ed > to support another PRNG. That one of the reason yes. >=20 > If new applications assume arc4random() is a high-quality CSPRNG and > generate long-term keys with it, they might have security issues on the > other systems where this is not the case. Yes, but it is an improvement for the Linux ecosystem nonetheless. Other systems, like Windows and MacOS are also moving on same direction. >=20 > I'm not sure what are the benefits of the current implementation. The benefits is to proper provide CSRNG, regaless on how the environment is deployed or configured, to avoid each library deploy wrong and insecure user-based alternatives. The vDSO discussion to speed up getrandom is still ongoing the main issue s= eems on who and how should be the one responsible to buffer management. The performance of arc4random was indeed initially taking in consideration [3] = (I even spent considerable time to adjust libgcrypt chacha20 optimized implementations). I wonder if we should add a GNU extension, arc4random_insecure or whatever, similar to what systemd does with 'random_bytes' that uses a user-managed buffer plus chacha20 or any other block cipher. And document it properly t= hat it was added as PRNG focused on speed.=20 [1] https://man.openbsd.org/arc4random.3 [2] https://developer.apple.com/library/archive/documentation/System/Conceptual= /ManPages_iPhoneOS/man3/arc4random.3.html [3] https://lore.kernel.org/linux-crypto/Ytx8GKSZfRt+ZrEO@zx2c4.com/ [4] https://github.com/systemd/systemd/blob/main/src/basic/random-util.c --=20 You are receiving this mail because: You are on the CC list for the bug.=