From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54562 invoked by alias); 11 Jun 2016 20:10:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 54544 invoked by uid 89); 11 Jun 2016 20:10:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=difficulty X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH] Add getrandom implementation [BZ #17252] To: Florian Weimer , Joseph Myers References: <20160610210303.6CE3E40141175@oldenburg.str.redhat.com> Cc: libc-alpha@sourceware.org From: Paul Eggert Message-ID: <8c990bc0-8e89-c69a-dc4b-58897f1b9b2b@cs.ucla.edu> Date: Sat, 11 Jun 2016 20:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00446.txt.bz2 On 06/11/2016 04:13 AM, Florian Weimer wrote: > programmers do not check for error returns from random number > generators. Based on that, I concluded it was important to provide an > implementation which cannot fail. Yes, as an app developer I prefer primitives like OpenBSD arc4random_buf that are always successful. In contrast, Linux getrandom (BUF, LEN, 0) is guaranteed to succeed only when called with LEN <= 256, which is good enough for hash nonces but not for general-purpose use. > Implementing arc4random has both libc aspects (providing thread safety > and invalidating the internal state around clone/fork) and > cryptographic aspects (for performance reasons, it has to be a > deterministic random bit generator, and use the kernel for seeding > only). I think the cryptographic aspect dominates, which is why it is > difficult to implement arc4random as part of glibc. Sorry, I don't understand. What's the difficulty? Why can't glibc implement the cryptographic aspect of arc4random_buf via an internal deterministic random bit generator? Can't glibc borrow a bit generator from Internet RFC 7539, or from GNU Coreutils, or whatever?