From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 16:19:04 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82792106566B; Wed, 8 Sep 2010 16:19:04 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7AE8FC15; Wed, 8 Sep 2010 16:19:04 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o88GJ3VN006624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Sep 2010 09:19:04 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C79C81CC3C; Wed, 8 Sep 2010 09:19:03 -0700 (PDT) To: Gleb Kurtsou In-reply-to: Your message of "Tue, 07 Sep 2010 21:46:18 +0300." <20100907184618.GA2611@tops> Date: Wed, 08 Sep 2010 09:19:03 -0700 From: "Kevin Oberman" Message-Id: <20100908161903.C79C81CC3C@ptavv.es.net> Cc: freebsd-current@FreeBSD.org, Robert Watson Subject: Re: RFC: pefs - stacked cryptographic filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:19:04 -0000 > Date: Tue, 7 Sep 2010 21:46:18 +0300 > From: Gleb Kurtsou > > On (07/09/2010 10:57), Kevin Oberman wrote: > > On Mon, 6 Sep 2010, Gleb Kurtsou wrote: > > > > > I would like to ask for feedback on a kernel level stacked cryptographic > > > filesystem. It has started as Summer Of Code'2009 project and matured a lot > > > since then. I've recently added support for sparse files and switched to XTS > > > encryption mode. > > > > > > I've been using it to encrypt my home directory for almost a year already, > > > and use fsx, dbench and blogbench for testing. So it should be fairly > > > stable. > > > > > > Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and > > > 8-STABLE supported. > > > > > > Please email me separately if you're willing to help testing on big endian > > > machine, XTS code doesn't look endian correct. > > > > > > At this point all of the project goals complete and I'd like it to get wider > > > coverage in terms of tests and reviews and hope to see it commited to HEAD > > > soon. > > > > I've got to ask a probably dumb question...how is this better then geli > > encrypted objects? I've used them for sometime with excellent results. > > > > Or does it provide functionality that geli does not? > > If geli works for you I'd suggest you continue using geli, geli design > is order of magnitude simpler due to being block device but not a > filesystem. Besides geli provides data authentication, which is very > important, and something that can't be easily implemented in stacked > filesystem. > > Pros of stacked filesystem approach: > * You don't have to create separate filesystem (use separate partition), > just encrypt part of existing filesystem > * It's easier to create/manage snapshots/backups (imho) > * Ability to use multiple keys, each directory can have its own key, > files with different keys can be mixed in one directory, etc. You > don't have to create another filesystem and claim that you don't know > password for this one if you're asked to provide it, in case you have > something to hide ;) > > Cons: > * pefs maximum file name length is ~180 bytes, but not 255 > * Stacked filesystem is likely to be slower due to extra overhead > > I don't really know what makes one better then other, it has only on > thing in common - encryption - everything else is different. It depends > on how you intend to use it. > > I was using geli myself, the only problem I had was that at some point I > realized that initial partition size was too small :) But that more or > less applies to both approaches. > > E.g. non-standard example where stacked filesystem may be preferred is > to use it for encrypted crash dumps: if dump available on dumpdev > mount /var/crash as pefs; ask user for password, or automatically add > random one and let user to save it later after boot. Crash dumps are > encrypted without extra cost of setting up partition, geli, etc. Thanks, Gleb. This explains it quite well and, yes, I will be sticking to geli as it meets my current needs (full disk encryption) quite well. I can see a potential use for pefs down the road, though. Thanks for all of your work on this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751