From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:24:29 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 53050F74 for ; Mon, 19 Aug 2013 07:24:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1524B27C2 for ; Mon, 19 Aug 2013 07:24:28 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j6so2937788oag.28 for ; Mon, 19 Aug 2013 00:24:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PTYnKTpQM6FMIlj8D70CLrFckCO02hAYlGs3bOqT05E=; b=azvPqd5gf0ZcGlqlWs9TevkSmO3nrg29edKyrjyHS15yO+fZZg4fnPPcjq64WTX2Xm A7A9IFx9J6y7SmsCywnyBWHcN9HQ6hHXnH9khjcCXniLECAFU1lR20XuJarWOBejGqW3 6AhXDGBOVcbm+YvdLC5pGI3zxaRALqMJsh1gHetoR0fuja9obpAR68PCzmsRUTDcNh2a zmPo93P4w1p2d8sXWKJF1240K2t7HQVArH1P1DdyPZIMjOszZr0+NWaXMMXsAELCJerT 3bP5AYEkcI4WZNzehxaYbBZ0ZqpOqDg8QYl5hBumJ3TYJEhe7Ej8mQD/uKTrXdvcmC2q 5KUg== X-Gm-Message-State: ALoCoQksEgDSQiroWgMjHmqM2YR8FZhnsR461GIZVoO5SM/uIx2S8FmBigHOi4tSYX7XoV8AN/Fp X-Received: by 10.182.96.169 with SMTP id dt9mr464009obb.76.1376897062116; Mon, 19 Aug 2013 00:24:22 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id d3sm15016581oek.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 00:24:21 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> Date: Mon, 19 Aug 2013 01:24:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> <86a9kf733d.fsf@nine.des.no> <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> <861u5r71zi.fsf@nine.des.no> <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> <86r4dr5j3p.fsf@nine.des.no> <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> <12B58C72-CFE3-4AD4-AD03-462A10E431D9@bsdimp.com> <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1085) Cc: Tim Kientzle , FreeBSD-arch Arch , secteam@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 07:24:29 -0000 On Aug 19, 2013, at 1:13 AM, Mark R V Murray wrote: >=20 > On 19 Aug 2013, at 08:09, Warner Losh wrote: >>> Besides Yarrow and Fortuna mixers, we could then >>> offer a "null mixer" option that selected the single >>> "best" entropy source and passed it directly through. >>=20 >> I'm still wondering why timecounters aren't the right model to follow = here, where you can have several compiled into the kernel and the one = with the best score wins. >=20 > How would they get a score, and how would it be decided which is = better? How is the score "calibrated"? For timecounters, we make judgements based on how good or bad we think = the timekeeping ability of the underlying device. I'd imagine that we'd = rate the hardware RNGs high, and the fallback means of harvesting = entropy from interrupts medium, and anything that's really really bad as = low. This would allow for the hardware RNGs to override the other = sources of entropy, while still allowing fallback to reasonable entropy = on devices that are known suspect (While still allowing the pig-headed = and/or externally constrained folks to use the bad sources). For the mixers, the scoring mechanism makes less sense. You'd want more = of an ordered list specified by the user to dictate policy to choose = between nothing, fortuna and yarrow. You'd also want a parameter to deal with failure here: panic or block. >>> Users could compile the null mixer into the kernel >>> and load a single HW RNG driver to have precise >>> control over /dev/random. Interrupt harvesting would >>> be the lowest-quality source as a fall back. >>>=20 >>> In particular, this has a reasonable failure mode if >>> someone built a kernel with only a single HW entropy >>> source and the null mixer: >>> * On hardware with that source, they would get >>> full-speed HW entropy. >>> * On hardware without that source, they would get >>> the old blocking /dev/random that we had before >>> Yarrow, the one that used only interrupt harvesting. >>=20 >> Assuming there was enough interrupt entropy to generate bits=85 >=20 > See Ferguson & Schneier on this (qv my follow-up). Saw that. I was worried only about starvation, but there's much more to = worry about than that it seems. Warner