From owner-freebsd-stable@FreeBSD.ORG Tue Apr 17 06:05:59 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDD2A16A401; Tue, 17 Apr 2007 06:05:59 +0000 (UTC) (envelope-from nik@mail.optim-mol.cemu.ru) Received: from mail.optim-mol.cemu.ru (mail.optim-mol.cemu.ru [83.102.188.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2402B13C44C; Tue, 17 Apr 2007 06:05:59 +0000 (UTC) (envelope-from nik@mail.optim-mol.cemu.ru) Received: from user-0cetl0n.cable.mindspring.com ([24.238.212.23] helo=[192.168.2.254]) by mail.optim-mol.cemu.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66 (FreeBSD)) (envelope-from ) id 1Hdgp8-000GRN-3b; Tue, 17 Apr 2007 10:05:57 +0400 Message-ID: <4624637D.40803@optim.com.ru> Date: Tue, 17 Apr 2007 01:04:45 -0500 From: Nikolay Mirin Organization: =?KOI8-R?Q?=EF=F0=F4=E9=ED?= User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Christian Brueffer References: <200704142307.l3EN72Sn031291@cs.wpi.edu> <46222EF7.1080507@optim.com.ru> <20070416162105.GA1592@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20070416162105.GA1592@haakonia.hitnet.RWTH-Aachen.DE> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: nik@mail.optim-mol.cemu.ru X-Myspam-check: OK X-Spam-Score: -100.1 (---------------------------------------------------) X-Spam-Report: Spam detection software, running on the system "mail.optim-mol.cemu.ru", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Anyway, the other reasons that GBDE suck are: 1) Lots of annoying ENOMEM messages, since the memory allocation calls gbde makes are somewhat specific as I understand. One can ignore those messages. 2) GELI provides a onetime key feature, which makes it incredibly convenient for swap and /tmp encryption. 3) The secret key in GELI can be split between the keyfile and the passphrase. [...] Content analysis details: (-100.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.3 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/why.html?sender=nik%40mail.optim-mol.cemu.ru&ip=24.238.212.23&receiver=mail.optim-mol.cemu.ru] X-SA-Exim-Connect-IP: 24.238.212.23 X-SA-Exim-Mail-From: nik@mail.optim-mol.cemu.ru X-SA-Exim-Scanned: No (on mail.optim-mol.cemu.ru); SAEximRunCond expanded to false Cc: mvoorhis@cs.wpi.edu, freebsd-stable@freebsd.org Subject: Re: GELI versus GBDE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 06:05:59 -0000 Anyway, the other reasons that GBDE suck are: 1) Lots of annoying ENOMEM messages, since the memory allocation calls gbde makes are somewhat specific as I understand. One can ignore those messages. 2) GELI provides a onetime key feature, which makes it incredibly convenient for swap and /tmp encryption. 3) The secret key in GELI can be split between the keyfile and the passphrase. The only inconvenience I had with GELI is that if one wants to read a passphrase in a script once and then open a bunch of volumes, than one has to use "expect" to feed the passphrase to geli. It requires the terminal input and won't accept the stdin. GBDE does not have such issue. P.S. One can actually have both in kernel. Christian Brueffer said the following on 16.04.2007 11:21: > On Sun, Apr 15, 2007 at 08:56:07AM -0500, Nikolay Mirin wrote: > >> Definitely GELI. >> >> GBDE will become obsolete very soon as some other things like vinum and >> such. It was there just as a test of concept as I understand. >> Many those different disk subsystems are incompatible in fact, the case >> of GBDE and Vinum is mentioned as an example in the handbook. >> Read more about GEOM, as this system will unite all possible disk >> techniqies. >> >> Also, GELI takes advantage of crypto-hardware, but I believe that one >> gets a benefit out of it only if the main CPU is very slow. >> >> > > There are currently no plans to remove GBDE. The problems with Vinum > you mention stemmed from the fact, that the original Vinum was not GEOM > aware, thus, GELI couldn't have been used with it as well. gvinum has > been in existance for some time now and it's fully compatible to both > GBDE and GELI. > > - Christian > >