From owner-freebsd-security@FreeBSD.ORG Sun Sep 23 13:59:58 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 84D60106566B for ; Sun, 23 Sep 2012 13:59:58 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC388FC0A for ; Sun, 23 Sep 2012 13:59:57 +0000 (UTC) Received: by eaac10 with SMTP id c10so202297eaa.13 for ; Sun, 23 Sep 2012 06:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=GkLguITEjqc9L3vJFZgUUoaRFdAhVbWFJh9vnBbZY+Y=; b=KKxIKCtUqk4Pi07oFWqC+YMVYjJ4qNQaxnZyLOJH29f/stJFQ2BrYMglPEq/u3tjXp wijIfeG9m/4rGbRN/nwxRb2Gv9eAziFQsh8k39SWlVBcaK/eWqV5/qMNTkXrPQr7i380 tvpUmDYxDbWayO3o+OLfHud3mGG6PqiBbh62W5FiykaSykaMGYrEfM9Jx4UMnl8Xtfvk OOoywnCZFZjo9QXBm4iopX0s2mfGbrm09LRdm5vRzXyIgjqJ7mAmtOi362FN9xd1s+PL fDazBCasJDJlA6ii8kVH51SPHaG9XnViKm7ZDcq6LSGPUp055AvRFwEPkDvt89IQetVY uIEQ== Received: by 10.14.218.134 with SMTP id k6mr11862531eep.14.1348408791671; Sun, 23 Sep 2012 06:59:51 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id k49sm38631226een.4.2012.09.23.06.59.49 (version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 06:59:50 -0700 (PDT) Date: Sun, 23 Sep 2012 14:59:45 +0100 From: RW To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-ID: <20120923145945.13d148e3@gumby.homeunix.com> In-Reply-To: <86lig3arpb.fsf@ds4.des.no> References: <20120918211422.GA1400@garage.freebsd.pl> <867grqm3pt.fsf@ds4.des.no> <20120919184758.28589516@gumby.homeunix.com> <86sjadt677.fsf@ds4.des.no> <20120920230133.55b63dea@gumby.homeunix.com> <86lig3arpb.fsf@ds4.des.no> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sun, 23 Sep 2012 13:59:58 -0000 On Sat, 22 Sep 2012 01:20:32 +0200 Dag-Erling Sm=F8rgrav wrote: > RW writes: > > They key will therefore *accumulate* entropy across multiple > > reseeds. >=20 > Forgot to address this. By definition, there can never be more > entropy in Yarrow than the key size. So it *does* throw away entropy > in the sense that if it accumulated, say, 900 bits of entropy > pre-boot (to pick one of the numbers Pawel cited), 650 of them are > wasted. I got fed up up of adding "up to 256 bits" and thought I could take it as read. Since the generator can only hold 256 bits and is secure well under that it doesn't really matter very much. Yarrow can't really be said to waste entropy since replacing entropy in the generator in a controlled way is what give it its ability to recover from compromise and break state extension attacks. If we're going to be pedantic it's only the generator that's limited to 256 bits, yarrow as a whole can accumulate up to 3x256 bits because the pools are not cleared on reseeds. There is some slight advantage in this, for example it means that two consecutive keys can be completely independent even on a fast reseed with a low value of kern.random.yarrow.fastthresh.