Re: RFC: pefs - stacked cryptographic filesystem

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.

> -- 
> 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