Date: Wed, 08 Sep 2010 09:19:03 -0700 From: "Kevin Oberman" <oberman@es.net> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: freebsd-current@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org> Subject: Re: RFC: pefs - stacked cryptographic filesystem Message-ID: <20100908161903.C79C81CC3C@ptavv.es.net> In-Reply-To: Your message of "Tue, 07 Sep 2010 21:46:18 %2B0300." <20100907184618.GA2611@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 7 Sep 2010 21:46:18 +0300 > From: Gleb Kurtsou <gleb.kurtsou@gmail.com> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100908161903.C79C81CC3C>