From owner-freebsd-security@FreeBSD.ORG Thu Sep 20 08:59:18 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 BDE8F106566C; Thu, 20 Sep 2012 08:59:18 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 603118FC14; Thu, 20 Sep 2012 08:59:18 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so2909924vcb.13 for ; Thu, 20 Sep 2012 01:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GiW76digtyeBc/WxwnY9CDBxgaEDcSK2vxl+vGv11p0=; b=BkA4TJVSCEctlEpWzGAeLAZVGNTjQE4jfPyqvhaIhi7uEhSyLxJ7r/Nfb2L4YKZzqn u3nMBWXmN1PFOOS0ytXlaSOXYxc128mG3kmkpj8mNYUxRJC9yvj9pcYDwqW1d9mxI7G5 2hSPXvEUBtZsaqU28yDcq6EwC7dYwYaj1g/amZiwye96LpYobWS0EEiEZpT2onK3rGbB FuYOv5KsY7ir3cMJDWgX3AL8B3725Co9qyZ3B9vvP0TJPq/W0/Cab7W61zNl3/y966eA d8v5NJGe/8g30E5jVSOwxC4CVAg4PGcHw+U2xc4yBIoyRbGO/wvJsDaOy+Z8QLWWyQT0 FAwg== MIME-Version: 1.0 Received: by 10.52.33.130 with SMTP id r2mr551301vdi.43.1348131557338; Thu, 20 Sep 2012 01:59:17 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.79.243 with HTTP; Thu, 20 Sep 2012 01:59:17 -0700 (PDT) In-Reply-To: <20120919202023.GD1416@garage.freebsd.pl> References: <20120918211422.GA1400@garage.freebsd.pl> <20120919192923.GA1416@garage.freebsd.pl> <20120919202023.GD1416@garage.freebsd.pl> Date: Thu, 20 Sep 2012 09:59:17 +0100 X-Google-Sender-Auth: UaVrM0fbwB_iNwEdi5vYHGro-Gk Message-ID: From: Ben Laurie To: Pawel Jakub Dawidek Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Jonathan Anderson 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 08:59:18 -0000 On Wed, Sep 19, 2012 at 9:20 PM, Pawel Jakub Dawidek wrot= e: > On Wed, Sep 19, 2012 at 08:59:15PM +0100, Ben Laurie wrote: >> On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek w= rote: >> > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote: >> >> > If all the times are more or less equally probable in this range [= =85] >> >> >> >> They're very unlikely to be equally probable. It would make sense to = do some characterization of these times and their statistics: a highly non-= uniform distribution would mean that we don't actually get many bits per at= tach. >> > >> > I have times for ~2000 device_attach() calls when loading sound card >> > driver on totally idle system. If someone could take those and analyse >> > the distribution that would be great. >> > >> >> > [=85] we have more >> >> > than 19 bits of entropy from this one call, but I reduced if to fou= r >> >> > bits only, because there are devices that are much faster to attach= . >> >> > >> >> >> >> Another reason for doing the above characterization is that, if a par= ticular device_attach() really does provide 12 bits of uncertainty, it's a = shame to drop eight of them on the floor. >> > >> > Rights. That's why I've prepared another patch: >> > >> > http://people.freebsd.org/~pjd/patches/harvest_device_attach.2= .patch >> > >> > which effectively discards top ten bits, which means we expect 0.1% of >> > the attach time to be unpredictable (the attach time in most cases var= y >> > by few percent, not sure yet how much of this variation is really >> > unpredictable). >> >> This is the wrong thing to do! There's no reason to discard bits on >> input (modulo the device throwing away inputs, that is) - just reduce >> your entropy estimate. "Extra" bits do no harm. > > I 'discard' ten bits from the estimation. I don't discard them by > zeroing them out. If the number is a 26 bit value then I feed entire > number, but pass estimation of 16 bits. Sorry, should've read the code first! This is great. I also like your friend's analysis.