From owner-freebsd-security@FreeBSD.ORG Fri Sep 14 13:38:12 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 CFE1B106566B; Fri, 14 Sep 2012 13:38:12 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 562578FC14; Fri, 14 Sep 2012 13:38:12 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B710425D385E; Fri, 14 Sep 2012 13:38:10 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B6DB6BE859B; Fri, 14 Sep 2012 13:38:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id zDTyEGEyccqS; Fri, 14 Sep 2012 13:38:08 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4E631BE859A; Fri, 14 Sep 2012 13:38:07 +0000 (UTC) Date: Fri, 14 Sep 2012 13:38:06 +0000 (UTC) From: "Bjoern A. Zeeb" To: David O'Brien In-Reply-To: Message-ID: 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> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Arthur Mesh , Ian Lepore , Doug Barton , freebsd-security@freebsd.org, RW , Mark Murray 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: Fri, 14 Sep 2012 13:38:13 -0000 On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote: Hi, I have removed freebsd-rc for this part of the discussion as it's unrelated. Ok, this is an aweful lot of individual parts and my feeling is that we want to go through them very focused. Some of them have been discussed enough already with good solutions but then found to depend on other things later. Some questions are clearly for "future research and not to be answered any time soon". The one I'd like to start with is the Problem of "over-seeding", as in that we are currently dropping possible entropy. The reason to start with that is: what and how we'll feed things in will depend on how we solve this problem. So far (wherever) I have heard multiple solutions and added some (unreasonable ones?) upfront to tick them off. I left my personal comments already. A simple "no" or "usable" can help; deleting all unreasonable options and "ACK" on OK ones can help. If i am entirely wrong, let me know in private. 1) continue to over-[fs]eed as we always did (seems out of question, no improvement) 2) compress (as in gzip) the input of better_than_nothing (multiple people objected, no literature, questionable outcome, speed, still not great control over how much data we seed) 3) hash (arch dependent?) the entire input of better_than_nothing in the shell script (at least a good idea on how much data we seed) 4) hash (arch dependent?) individual parts of better_than_nothing in the shell script (seed more and still know how much data we'd seed) 5) send all data to the kernel but XORing the data together on overflow in the kernel (can control when buffer full and only then take action when needed, indepedent on how seed data is chosen, withdrawn) 6) send all data to the kernel but XORing the data + counter value together on overflow in the kernel (can control when buffer full and only then take action when needed, indepedent on how seed data is chosen, but why XOR?) 7) send all data to the kernel and hash (arch dependent?) it + counter value into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in the kernel (can control when buffer full and only then take action when needed, indepedent on how seed data is chosen, uses standard technology) 8) ? Things to consider: overall time this takes? Things to consider: how often this needs to be done? Things to consider: how to consume the most entropy? Things to consider: can it be done arch specific if needed? Things to consider: would there be a challenging problem implementing this? ... Things I really love not to hear in this step: - discussions on how much seed data/entropy we send - discussions on which seed data/entropy we send - discussions on the order of seed data/entropy we send - ... Thanks, /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.