From owner-freebsd-geom@FreeBSD.ORG Fri Dec 7 17:14:44 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B71A016A420 for ; Fri, 7 Dec 2007 17:14:44 +0000 (UTC) (envelope-from hg@queue.to) Received: from pickle.queue.to (pickle.queue.to [71.180.69.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4482413C447 for ; Fri, 7 Dec 2007 17:14:43 +0000 (UTC) (envelope-from hg@queue.to) Received: (qmail 20973 invoked from network); 7 Dec 2007 12:14:42 -0500 Received: from cally.queue.to (172.16.0.6) by pickle.queue.to with ESMTP; 7 Dec 2007 12:14:42 -0500 Message-ID: <47597F82.5020608@queue.to> Date: Fri, 07 Dec 2007 12:14:42 -0500 From: Howard Goldstein User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Pawel Jakub Dawidek , freebsd-geom@freebsd.org References: <4758A55B.7000205@queue.to> <20071207163540.GE8318@garage.freebsd.pl> In-Reply-To: <20071207163540.GE8318@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: geli key without key file X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 17:14:44 -0000 Pawel Jakub Dawidek wrote: > On Thu, Dec 06, 2007 at 08:43:55PM -0500, Howard Goldstein wrote: >> If I create a geli volume without specifying a -K newkeyfile as in the >> handbook example that dds /dev/random to a 64 byte file, would a >> reasonable passphrase result in geli init creating a reasonable key for >> the AES or Blowfish encryption implementation? > > Yes. > Thanks, and also thank you very much for all that you've done architecting and implementing geom and its various classes for us. I'd be surprised if it weren't used as a model for folks pursuing a software engineering degree. (Sorry about the bounces, there was cruft in tcp.smtp erroneously knocking out your provider, and it's gone now)