From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: /dev/urandom Date: Tue, 10 Jul 2018 14:43:23 -0400 Message-ID: <87601nylro.fsf@netris.org> References: <20180710182211.75442f8b@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcxd9-0002F3-8Z for guix-devel@gnu.org; Tue, 10 Jul 2018 14:44:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcxd4-0000Xz-CM for guix-devel@gnu.org; Tue, 10 Jul 2018 14:44:55 -0400 Received: from world.peace.net ([64.112.178.59]:52822) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fcxd4-0000Jt-8I for guix-devel@gnu.org; Tue, 10 Jul 2018 14:44:50 -0400 In-Reply-To: <20180710182211.75442f8b@scratchpost.org> (Danny Milosavljevic's message of "Tue, 10 Jul 2018 18:22:11 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel@gnu.org Hi Danny, Danny Milosavljevic writes: > u-boot tools/sunxi-spl-image-builder.c reads from /dev/urandom . > > For reproducibility I'd like this to be a static file. Do we already have one > for this purpose? I think it would be better to patch software as needed to avoid trying to generate random numbers in specific places, mainly because it would force us to always be aware of what the random numbers are being used for, so that we can evaluate the potential security implications. If we simply make /dev/urandom deterministic, then we will not be in the position to know what the (non)random numbers are being used for, and we run the risk of introducing serious security issues. Note that it would not be sufficient to audit the software once to see what the random numbers were being used for, because future versions of the software might add additional uses for random numbers. If that ever happens, then the difference between the two approaches will become important. If we make /dev/urandom deterministic, then new uses for random numbers introduced in future versions will be *automatically* made non-random, and we might not notice. On the other hand, if we patch out specific uses of randomness, then new uses for randomness will be left intact until we add patches for them. This is as it should be, I think. What do you think? Mark