Re: RFC: pefs - stacked cryptographic filesystem

From: Kevin Oberman <oberman_at_es.net>
Date: Wed, 08 Sep 2010 09:19:03 -0700
> 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 3751
Received 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