From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 18:20:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE69B72A for ; Fri, 18 Jul 2014 18:20:06 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52FE12FD5 for ; Fri, 18 Jul 2014 18:20:05 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so3147847lbd.36 for ; Fri, 18 Jul 2014 11:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V76cdOviVzmREDFpW/adxhHCf5O/rJO47TjfnWGgIB0=; b=cmyvle/Dy+WbRf0RatysJF7bdJAQD5qcO+n+zV1ip/3B5bGMUcu/tQouU2BycHnYUT VB42kA9qFXxZ6qOO+8WzlpTS5qy8iJV3sMSoKAo7QdEl474WuIgNwGOPVPN6CEbsDgWv gZCiEFaETayTo9KBrTmfKdsR3iuSpcgGqDjWfZo2onh412AYUXM0XoquxeLFl0ub1/XU G9CcCVUIBH4Rb3KnOBttXkfgy0uSo9C1+PLwCFl1zbLx+F2quHdKH6lzRs/JTwz9Oge9 BGKWQ01iRkmRZLV7RLW+yenIsq5x4+rrmKY8biGMIMkcYfjZUzaELCbHMdEzZAaoLEjG j5zA== X-Gm-Message-State: ALoCoQn/aGryfGJ2/lyFD34uPfBJs6QcKxRAa/00My31R61OyDIq/FaVbc5ipded4USoHTToY1Bk X-Received: by 10.152.3.65 with SMTP id a1mr7349891laa.76.1405707598470; Fri, 18 Jul 2014 11:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.149.65 with HTTP; Fri, 18 Jul 2014 11:19:18 -0700 (PDT) X-Originating-IP: [24.111.146.222] In-Reply-To: <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> From: Leif Pedersen Date: Fri, 18 Jul 2014 13:19:18 -0500 Message-ID: Subject: Re: Speed and security of /dev/urandom To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-security@freebsd.org" , Steven Chamberlain X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 18:20:07 -0000 On Fri, Jul 18, 2014 at 9:26 AM, Paul Hoffman wrote: > On Jul 17, 2014, at 4:41 PM, Steven Chamberlain > wrote: > > > * after seeding, some arc4random implementations completely forget to > > reseed after the process forks - the same 'random' stream of bytes could > > occur twice, with security implications > This is a compelling argument to avoid doing crypto in isolation. One need not do it in the kernel to avoid this (could implement a userland crypto with a daemon that exports a pipe/socket), but the approach of seeding an isolated algorithm that could wind up cloning it's memory space and therefore the seed for the next value seems suboptimal. > > (There's also the benefit that having many readers from a single > > pseudorandom stream, adds an additional kind of randomness to its > output). > > How does having an additional *reader* add additional bits? > > The extra readers interrupt the position of the stream, so that it is harder to predict the next value. This only works if one instance of the PRNG is shared by multiple readers, rather than each reader operating in isolation. > This is obviously a complex issue, and some of it will be subjective. > > But I welcome your comments. Thanks! > > Subjective wins. > It's disappointing when emotions bewilder clear rational thinking. I think his point is well stated. Seeding a PRNG from another PRNG (such as seeding arc4random from FreeBSD's Yarrow-backed /dev/random) increases risk since if the seed is compromised then the dependent is also. Not to confuse that with xoring the output of two PRNGs, which can't hurt and may help. I read that sending all hardware randomness through Yarrow is in response to the questionable trustworthiness of hardware randomness; fair enough. It then seems to me that all programs should leave stretching the randomness to the kernel (or other shared resource) rather than instantiating arc4random or the like and only spooning out a little of the result to seed. That way, if the algorithms or randomness backing /dev/random is compromised, one need only patch one piece of software rather than many. Better yet, an operator can potentially choose this or that algorithm system-wide with sysctl, if multiple become available and one is compromised. In the final analysis, if OpenSSL really can't trust /dev/random, then it should xor the stream from /dev/random with its internal arc4random stream, not merely seed arc4random from Yarrow, but even better to solve the trust problem in the kernel rather than solve it selfishly in OpenSSL only for OpenSSL. - Leif -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig