From owner-freebsd-security@FreeBSD.ORG Thu Sep 20 07:32:38 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 529B3106566B for ; Thu, 20 Sep 2012 07:32:38 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3743E8FC16; Thu, 20 Sep 2012 07:32:38 +0000 (UTC) Received: from [::8097:fb14:100:0] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8K7WaR4066803; Thu, 20 Sep 2012 07:32:37 GMT (envelope-from jonathan@FreeBSD.org) Date: Thu, 20 Sep 2012 08:32:36 +0100 From: Jonathan Anderson To: RW Message-ID: <10CD8D9A9ADB484694DE4DCBD9594FAB@FreeBSD.org> In-Reply-To: <20120919214624.2f6682a2@gumby.homeunix.com> References: <20120918211422.GA1400@garage.freebsd.pl> <20120919192923.GA1416@garage.freebsd.pl> <20120919214624.2f6682a2@gumby.homeunix.com> X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-security@FreeBSD.org Subject: Re: Collecting entropy from device_attach() times. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 07:32:38 -0000 On Wednesday, 19 September 2012 at 21:46, RW wrote: > extra bits may make the difference between secure and insecure I'm sorry, this may be a bit pedantic, but I have to object to the terms "secure" and "insecure" used without qualification. :) Perhaps you mean "predictable" and "unpredictable"? Believe it or not, this is a serious point rather than just nit-picking: there are all kinds of things that we might want to do with "random" numbers during boot, but not all of them require unpredictability in the face of an adaptive adversary. When generating a random MAC address (sys/arm/at91/if_ate.c:305), we don't need unpredictability, we just need per-machine uniqueness. When using a random delay to prevent things happening in cyclical lockstep (sys/kern/kern_synch.c:563), we don't even need that: we just need *some* things to get different delay values. So while cryptographic ("secure") randomness is always sufficient, it's not always necessary, especially in very simple machines that have a hard time harvesting entropy early in the boot process. This is part of why I'd like to see us move to a more descriptive API: - fuzz_value(range) - unique_value(range) - unpredictable_value(range) or something like that, instead of committing to particular algorithms (arc4random) or (in userspace) telling /dev/random to "get me some random, whatever that happens to mean". The implementation of each of these functions could start with "if I have a properly-initialised PRNG, use that", but for code that doesn't require true unpredictability, it might be good to just carry on booting with only-slightly-random numbers rather than wait for entropy estimates to hit the cryptographic threshold. But that's a discussion for another (future) thread. :) Jon -- Jonathan Anderson jonathan@FreeBSD.org (mailto:jonathan@FreeBSD.org)