On 7/26/06, Johan Wall=E9n <johan.wallen+lists@tkk.fi> wrote:
> There seem to be two ways to work around this problem:
>
> (1) Integrate the IVs in the filesystem (that is, the IVs are somehow
>     part of the metadata of the filesystem).  Then you would have a
>     natural place to store the IVs.

In this case, cgd is done at the block level, and the file system
layer is above it.  The pseudo-block device is filesystem agnostic.

Generally speaking, there are three places to do encryption of secondary st=
orage

1) You can do it at the application layer in a stand-alone program,
like GPG or "vi -x", in which case en/decryption is not automatically
done by the OS but must be done by the user.

2) You can do it at the file system level, like TCFS, CFS, and a few
other filesystems.  This has the disadvantage of being relatively tied
to the internal filesystem OS APIs, increasing the difficulty of
porting it and overall being fairly complex.  One can, however,
introduce dependencies in the form of chaining modes that apply to an
entire file.  As a layer, you can mount this over another kind of
filesystem, although how you store metadata then becomes problematic.
CFS does this by using symlinks.  Most Linux file systems have support
for arbitrary attributes now, so this is a cleaner way to handle it.
If you don't layer this over another file system that specifically
handles storage, then you are duplicating a lot of code and increasing
the complexity quite a bit by trying to handle both functions at once.
 If you want to encrypt metadata like file names, you are introducing
a length limitation and must worry about unwanted characters like ".",
"/" and \0 showing up in the lower layer.  You can back up the lower
layer in the layered case, allowing for incremental backups but not
allowing significant compression.  Otherwise, you'll be backing up
plaintext.

3) You can do it at the device level, like cgd and Linux loopback
encryption.  This has the disadvantage of usually having to be the
same size as the decrypted data, or having a complex mapping from
"visible blocks" to "physical blocks" (the most natural place is in a
fixed-size header).  All semantic information about different blocks
belonging to the same object (file) is lost before being passed to
this level, so basically each sector is independent of every other.
This has the disadvantage that backup must either be of the plaintext
filesystem over it, or the entire encrypted partition.

It may well be that some efficiencies may be found by combining levels
of abstraction, like in the wickedly cool zfs which implements
copy-on-write functionality in the file system, but so far
experimentation with file systems in a monolithic kernel has proven
sufficiently difficult that not much progress has been made, and the
extant implementations are deeply wedded to the OS and often the
particular version of the OS, with the possible sole exception being
the venerable CFS, which pretends to be an NFS server.

The trend seems to be towards option three.
--=20
"if you're not part of the solution, you're part of the precipitate"
Unix "guru" for rent or hire || http://www.lightconsulting.com/~travis/ -><=
-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484