From owner-freebsd-security@FreeBSD.ORG Sat Sep 15 10:59:35 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 58858106566C; Sat, 15 Sep 2012 10:59:35 +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 8D81B8FC08; Sat, 15 Sep 2012 10:59:34 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so7483369vcb.13 for ; Sat, 15 Sep 2012 03:59:33 -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; bh=FTcLRPp+ui4mFNpAnjBPif/wC0hIM5Zza6MG0oOAraA=; b=KEg0Tnd4Kl+SplHsabWZHzhYNebvqKhLE3l++50f2qFc3JHAfq+J2RbUBchbeeo1jx j7Lf53tgWEL5Mbw+CORbWPZVlVCUI0tuJlJsIm37OPBojlFpitUdq6CsRetZYg2CeHWW P8Hd5Ac4Msvjmp4Ypy6typS3L5vsJnPLeVY7E1AoPp9KL3nff6/mb/KLYUDG31OZnXIk v3XdIyvgi/CcFa3lKoRBEZSSQDfPStWghuPtzIlGoHQi6qtbl4pEByF3dE12kRhETN4g rRrJlFIGAItXyI59zu+9/qDN8PCjnIZ4WiEvXKHl5I4Xx8FEW/GhV+BES7w0OY1MT2i8 1fzg== MIME-Version: 1.0 Received: by 10.58.59.36 with SMTP id w4mr4600249veq.26.1347706773572; Sat, 15 Sep 2012 03:59:33 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.79.243 with HTTP; Sat, 15 Sep 2012 03:59:33 -0700 (PDT) In-Reply-To: References: <50453686.9090100@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <504F0687.7020309@FreeBSD.org> <201209121628.18088.jhb@freebsd.org> <5050F477.8060409@FreeBSD.org> <20120912213141.GI14077@x96.org> <20120913052431.GA15052@dragon.NUXI.org> Date: Sat, 15 Sep 2012 11:59:33 +0100 X-Google-Sender-Auth: ulm9kRQdO-q9uDJScYLyB4ZKENI Message-ID: From: Ben Laurie To: Mark Murray Content-Type: text/plain; charset=ISO-8859-1 Cc: Arthur Mesh , Ian Lepore , Doug Barton , freebsd-security@freebsd.org, RW , "Bjoern A. Zeeb" Subject: Re: svn commit: r239569 - head/etc/rc.d 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: Sat, 15 Sep 2012 10:59:35 -0000 On Sat, Sep 15, 2012 at 11:36 AM, Mark Murray wrote: > Ben Laurie writes: >> > I can certainly trigger a reseed at will, but allowing external writes >> > to overwhelm the system by doing a >> > >> > $ cat /dev/zero > /dev/random >> > >> > ... just ain't gonna happen. No, sir. >> >> Let's just quantify the risk here: essentially the problem is that if >> I feed something with no entropy into the pool and that is allowed >> to trigger a reseed, then you end up hashing what existing entropy >> you have with the no-entropy input, leading to a loss of entropy. The >> theoretical loss for a perfect hash function is log_2(N)log_2(1/e), >> where N is the number of iterations. log_2(1/e) is ~.66. So, to reduce >> the entropy from, say, 256 bits, if SHA-1 is used, to 128 bits, takes >> ~2^(128/.66) reseeds - that is, ~2^193. Around 10^58. So, you're >> right, it ain't gonna happen, even if you allow an attacker to reseed >> as often as he wants :-) > > Fine, but that is not what I'm talking about, _AT_ALL_. > > Reseeds are expensive in kernel space; locking/unlocking and thread > consumption are the issue. Right now, this is mitigated by reseeding at > 10Hz. To allow reseeds to overwhelm the running kernel by pumping data > into /dev/random is would be very silly indeed, and I'm not going to let > that happen. I'm curious what the comparative cost of cat /dev/zero > /dev/null is? Or, cat /dev/zero > somefile