From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6961 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general Subject: Re: getrandom syscall Date: Mon, 09 Feb 2015 12:37:49 -0800 Message-ID: <54D91A9D.4000403@amacapital.net> References: <20150128154108.GH32318@port70.net> <20150128160352.GI32318@port70.net> <20150128162104.GJ4574@brightrain.aerifal.cx> <20150128191746.GK4574@brightrain.aerifal.cx> <3AC86046-063E-4437-9BF6-F411E7C8C6E9@gmail.com> <20150128220229.GL4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1423514318 29285 80.91.229.3 (9 Feb 2015 20:38:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Feb 2015 20:38:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6974-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 09 21:38:38 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YKv6M-0004Zz-6l for gllmg-musl@m.gmane.org; Mon, 09 Feb 2015 21:38:38 +0100 Original-Received: (qmail 1367 invoked by uid 550); 9 Feb 2015 20:38:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32748 invoked from network); 9 Feb 2015 20:38:03 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=csfoLRSUdmZu+Azq0NldUPzdFx8mras+tjiDaWwYSes=; b=arLtBqh8HMBzoLHm4lkxV8fDFyjOZDualqcvKSGupoSzK/EvDYGtJTk9hNEyoRhQrS eOA+w6Xr1ps498nJYqXjJdazIBHXUP4bECrQ1Xl5/tqNr61FQMaaD+MKOsP4KOXD/T1v jTFiHwC48flBsBWl/rde5iUAvXhalZ2e22t/1O8x7fpp1vA6cJrxJZOBopGrxMBeY74d F7FT7R06VbW5Fefl4Lx9EYEE83bhvCiPpcG66rE+8uG2o/fkwV6JAyFpxtOEEYGZQMiT n/mKjZPArBSTdEI542T+PM+Bep+eWNktdx1S9iqmEFCxP4bEmK+2/Um7JAfPkH+A1CNq d8oA== X-Gm-Message-State: ALoCoQnEcJ/GWSSI8WxFXD/tnCIbe0GqD8BT+5qVVGN6vLUgUA7P2/IthnXqTVkL3XxZaCVIXrlZ X-Received: by 10.68.136.137 with SMTP id qa9mr31915452pbb.127.1423514272025; Mon, 09 Feb 2015 12:37:52 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <20150128220229.GL4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6961 Archived-At: On 01/28/2015 02:02 PM, Rich Felker wrote: > On Wed, Jan 28, 2015 at 02:20:16PM -0600, Brent Cook wrote: >>>> It tries to avoid a couple of possible issues. FIrst, while <= 256 >>>> byte getrandom should not interrupt, it appears that if the kernel >>>> entropy pool has not been initialized yet, it would still return EINTR >>>> if called early enough in the boot process. How likely this is in >>>> practice, I don't know. >>> >>> You mean it would block and be subject to EINTR if a signal occurs? In >>> this case I would think you'd probably _want_ the EINTR to cause it to >>> fail. I can imagine an early-boot program using SIGALRM to prevent >>> waiting too-long/forever for entropy that's not going to arrive. >> >> Yes, that is a better description. Failing when receiving EINTR to avoid >> an infinite loop is an interesting idea, but getentropy is documented >> as only failing under a very narrow range of conditions: >> >> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 > > OK. The conditions for EIO are left sort of open-ended, but it seems > the intent is that this function not fail with valid inputs. I think > we should follow that intent if we provide the function, which means > both ignoring EINTR and providing a fallback for ENOSYS. > >>> So, their version of getentropy is aiming to provide a meaningful >>> result even on systems that don't have SYS_getrandom. Should we be >>> doing the same? >>> >>>> If a getentropy() were added to musl libc, but in such a way that it >>>> might fail on older kernels, that would cause some problems with >>>> LibreSSL, and now OpenNTPD. They will both try to use getentropy() >>>> with arc4random() if it is found in a system, and arc4random() will >>>> treat a getentropy() failure as fatal. >>> >>> Yes, this sounds bad. So what fallbacks should we implement? Do we >>> need a strong CSPRNG on top of AT_RANDOM? >> >> You can see a variety of fallbacks there, and AT_RANDOM is included, >> though that is not available on every kernel either. If you're going to >> implement such a CSPRNG, the C library seems the place to do it though. > > At this point I think what's clear is that we should provide the > syscall wrapper for getrandom. What to do with getentropy is less > clear, and it looks to be a fair bit of work/code-size to get a robust > getentropy suitable for application usage. > > I don't want to copy the idiotic stuff libressl is doing, but I think > the following fallback sequence would be reasonable: > > 1. Try SYS_getrandom. Fails on even mildly-old kernels. > > 2. Try opening /dev/urandom. Fails under fd pressure or broken > chroots/containers/lsms/etc. > > 3. Try AT_RANDOM+CSPRNG. Fails on ancient (what version?) kernels. > > I don't know what to after that, but I suspect/hope that any kernel > too old to have AT_RANDOM is full of so many gaping security holes > that lack of working entropy source is the least of anyone's problems. > > As for CSPRNG, what would be acceptably small and secure? CTR mode > using a block cipher and AT_RANDOM as the key? Could we reuse crypto > code out of crypt/*.c? Or just call crypt_r directly? Something backword secret (maybe the wrong term) would be nice, e.g., new_state, output = PRF(old_state). This has the property that a leak of memory contents heartbleed-style doesn't leak *prior* CSPRNG outputs. Defining PRF(x) = SHA256(x) with x being 128 bits is probably fine. That is, new_state is the first 128 bits of SHA256(old_state) and the output is the next 128 bits. The quantum cryptographer in me would prefer 256-bit state, though, but I'm not sure that makes any sense in practice with AT_RANDOM. I am not a serious cryptographer, so this should be taken with a small grain of salt. If you wanted to depend on having an implementation of the Keccak sponge around, then there are very simple and much cleaner CSPRNGs in the literature that I could point you to, but they have the disadvantage of using larger internal states and therefore more memory. Using a 128-bit state has the benefit that it could reuse the memory already allocated to AT_RANDOM. --Andy