From owner-freebsd-security@FreeBSD.ORG Sat Sep 15 11:41:53 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98AA106566B; Sat, 15 Sep 2012 11:41:52 +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 37D308FC16; Sat, 15 Sep 2012 11:41:51 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so7508243vcb.13 for ; Sat, 15 Sep 2012 04:41:51 -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=lpPi4tkJF9DvVWlrBmNkEAihDbzbDLd48R3txUHy7IQ=; b=ZSuaPOXMAMkbfVE7xsMSFF4ZfQ/qSM5EjZZv9t+j0ikrfph9Ub4UsRqHFM70fU41DP P6qUBcyBy66sI9vR/gUQzNgLV1tWlLnl/E72fvlZ9Du6BCk88w7o0vBbCSYzv8wPISc4 5yG5IE7DyATEzFsS/WAc3EUATWl1oUfbkkGHGrKrNRdHNn5C7d+4QoBVY1Lc2qiVihiv Url/kVMCtJJfstM0cwRFbK7r4G8NKcnqAXUJkhD3nBTiqryzGkFe6V+lpDaofz/oMQNA ca6/dhgchB1y2N3XOWSZ/Wr9NsVF2CdQVcfSTjpMuYbJh0/qeSUxpbv8/JzbS+cew97I lzJA== MIME-Version: 1.0 Received: by 10.220.157.65 with SMTP id a1mr4366562vcx.39.1347709311452; Sat, 15 Sep 2012 04:41:51 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.58.79.243 with HTTP; Sat, 15 Sep 2012 04:41:51 -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 12:41:51 +0100 X-Google-Sender-Auth: TM-QZ6Qw44Shy0jM4D52gNqC-Y8 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 11:41:53 -0000 On Sat, Sep 15, 2012 at 12:07 PM, Mark Murray wrote: > Ben Laurie writes: >> > Are you aware of Yarrow's approach to poor entropy while harvesting? >> >> Yes. I am _only_ talking about fixes for the current practice of >> discarding input - once Yarrow gets to eat input, then its all fine, >> but as you say, you don't want to run Yarrow over all input because it >> is too expensive. > > Correct. > >> So, you plan to xor input with itself, instead of discarding if it >> fills the buffer. My point is that unfortunate choice of input can >> result in the input cancelling itself out. > > That means that diverse input should be used, and that is the intent > anyway. > > Hashing _certain_ input in /etc/rc.d/initrandom is also attractive. > >> This is not part of Yarrow - Yarrow specifies that you hash all >> inputs, not xor or discard them :-) > > Beyond nitpicking. How the data is harvested is not discussed in much > detail. It says that the pools contain the running hash of all inputs fed to them since they were last used to reseed. It is _not_ "beyond nitpicking" to observe that neither xor nor discard are hashing. _Particularly_ when you suggest that my criticism arises from ignorance of Yarrow! The whole point of Yarrow is to extract all available entropy by the use of hash functions. If you do something else, then you are not doing Yarrow. That said, as I understand your proposed code, what you are doing is xoring each complete input into a HARVESTSIZE buffer, then submitting that as an event - so the problem only arises if a single input repeats internally. It might be a good idea, assuming we go down this path, to add a note to the man page pointing out that: cat a > /dev/random cat b > /dev/random is wiser than: cat a b > /dev/random I remain surprised that the cost of hashing the input into a HARVESTSIZE buffer is noticable after all the other costs of the system call, though. > Here, I'm chunking the file input up, instead of taking it > piecemeal. In each case, the harvested data is handed over to Yarrow as > a series of data "events". Keystrokes, mouse events, interrupts or uio() > calls are all such events, and many more are possible as input. I notice that events are also discarded when the queue reaches a certain length. This seems like a problem, too.