> Date: Tue, 7 Sep 2010 21:46:18 +0300 > From: Gleb Kurtsou <gleb.kurtsou_at_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_at_es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751Received on Wed Sep 08 2010 - 14:19:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC