From owner-freebsd-hardware@FreeBSD.ORG Sat Oct 14 14:04:09 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D38E216A47B for ; Sat, 14 Oct 2006 14:04:09 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE6CF43DAA for ; Sat, 14 Oct 2006 14:03:49 +0000 (GMT) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 14815 invoked from network); 14 Oct 2006 14:03:49 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Oct 2006 14:03:49 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id D0E722842E; Sat, 14 Oct 2006 10:03:48 -0400 (EDT) To: soralx@cydem.org References: <78ED28FACE63744386D68D8A9D1CF5D4209C94@MAIL.corp.lumeta.com> <20061012075101.Y5008@ketralnis.com> <200610140308.00451.soralx@cydem.org> From: Lowell Gilbert Date: Sat, 14 Oct 2006 10:03:48 -0400 In-Reply-To: <200610140308.00451.soralx@cydem.org> (soralx@cydem.org's message of "Sat, 14 Oct 2006 03:07:59 -0700") Message-ID: <44wt738057.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hardware@freebsd.org Subject: Re: Quiet computer X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2006 14:04:09 -0000 soralx@cydem.org writes: >> > mentioned cpu, but a 100x speed difference? That doesn't seem realistic >> > to me (although if those are valid results, I'd be pretty happy with >> > that)... >> >> Well, the Via Padlock has a hardware random-number generator, so the >> idea was to test that. It doesn't claim to be fast, just to be truly random > > Precisely. However, speed of the crypto engine should be directly > proportional to a peak speed of the RNG, That statement makes no sense to me. Why would the RNG be relevant after the session keys are established? > so I thought that it's > slow speed might confirm that the engine is being used, and is > simply slow. I don't really care how fast the crypto engine is on my Via system. I just care that it offloads the ALU. I haven't gotten around to proving whether (and by how much) it does so. > Also, we didn't really test where are those random bits coming from :P > Is the TRNG used by default, or some tinkering's in order to make it work? > > BTW... `ubench`? :) Not impressive.