From owner-freebsd-hackers@freebsd.org Tue Jul 14 13:30:27 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0087D99B0D9 for ; Tue, 14 Jul 2015 13:30:27 +0000 (UTC) (envelope-from vsevolod@FreeBSD.org) Received: from mail.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:190:43b5::99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B821737E for ; Tue, 14 Jul 2015 13:30:26 +0000 (UTC) (envelope-from vsevolod@FreeBSD.org) Received: from secret-bunker.localdomain (unknown [81.145.134.172]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 5706D300129; Tue, 14 Jul 2015 15:30:16 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by secret-bunker.localdomain (Postfix) with ESMTP id A32E2626D1E; Tue, 14 Jul 2015 14:30:17 +0100 (BST) Message-ID: <55A50EE9.1020900@FreeBSD.org> Date: Tue, 14 Jul 2015 14:30:17 +0100 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yuri , Freebsd hackers list Subject: Re: Does /dev/random in virtual guests provide good random data? References: <55A2FB68.3070006@rawbw.com> <55A3763B.7010303@rawbw.com> In-Reply-To: <55A3763B.7010303@rawbw.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 13:30:27 -0000 On 13/07/2015 09:26, Yuri wrote: > On 07/12/2015 18:14, Tim Kientzle wrote: >> http://www.2uo.de/myths-about-urandom/ >> >> In particular, it has this interesting comment: >> >> FreeBSD does the right thing: they don't have the distinction > > There are two approaches in random stream generation. One is to have the > sufficient random seed, and keep generating the following pseudo-random > numbers only from this seed. The second approach is to also continuously > feed the stream from some external source of entropy. > > The fact that the long running linux VM still blocks on /dev/random > indicates that linux tries to collect more entropy on the go, following > the latter approach (intuitively I would also agree this is better for > randomness). > > So it isn't clear why FreeBSD random stream would be of the same > quality, if it doesn't collect entropy on the go. Because both Linux and > BSD have exactly the same entropy sources in VM. That's *not* the correct definition of how the modern PRNG work. In both Linux and FreeBSD there are a single or multiple pools of entropy that are seeded from many entropy sources (the algorithm of entropy distribution among pools can vary). These pools are used to seed generator which subsequently generates blocks of pseudo-random data. A cryptographic PRF (such as AES-CTR) is used for generator, hence, by definition, there are no *efficient* ways to distinguish its output from purely random. Moreover, since it is seeded with true random data, an attacker cannot predict the subsequent data without controlling *all* entropy sources in system. The key difference between FreeBSD and Linux is that in Linux, /dev/urandom *never* blocks which is bad: on boot, when there is no entropy gained, it is really a bad idea to generate something like SSH keys. On the contrary, FreeBSD /dev/urandom will *block* if there is no entropy in the pools. In conclusion, it is always safe to use both /dev/random and /dev/urandom in FreeBSD and it is safe to use /dev/urandom in Linux almost all the time but not before the initial entropy harvesting that occurs on boot (but you can check the amount of entropy in the pools prior to generating something sensible, e.g. keys generation or DSA/ECDSA). There are some improvements in the Fortuna algorithm that's going to replace Yarrow in the HEAD. They are negligible for the most systems but are quite useful for low entropy systems (but there are no practical attacks on yarrow as well AFAIK). -- Vsevolod Stakhov