Re: file-level encryption in userland with HAMMER{2}?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:It would be nice if there is any interesting implementation of both
:block-level encryption at admin-level and file-level encryption
:(something like ciphertite) in userland with HAMMER{2}.
:
:Appreciate some inputs. Thanks!
:
:PS: Desperately waiting for HAMMER2, any updates, please?!

    It's still a long way off in terms of clustering and mirroring but the
    core filesystem will be usable in a stand-alone mode with certain
    restrictions in the next few months.

    There are three major pieces still needed for stand-alone operation.
    Two related to the free block table (including the code to actually
    free blocks :-)), and a solution for a known hardlink bug related to
    renaming directories.  Secondary issues are /boot support (not critical,
    even hammer1 doesn't really have working boot support), and some sort of
    catastrophic recovery utility.

    In terms of encryption, the media spec has support for it.  Nothing is
    currently implemented.  It will be fairly easy to encrypt the actual
    file contents.  Encrypting the inodes and filenames at the filesystem
    level requires a bit more thought.  I think we could encrypt filenames
    without too much effort but encrypting the inodes (at the filesystem
    level) might be a bit too much.  Also, encrypting the directory hash
    keys (a 64 bit quantity) might also create too many issues though I can
    see how it could be done.

    An encryption implementation would make use of hammer2's configuration
    entry space, which supports 255 configuration slots used for various
    things (such as specifying where the copies are when the copies mechanism
    is used).  Slots could be used to store up to 512-bit master keys
    (encrypted with an unlocking password) and the unlocked master keys
    could then be used to encrypt/decrypt data.  The mechanics are fairly
    straight-forward.  The Hammer2 compression GSOC project infrastructure
    can be expanded later on to also accomodate encryption and decryption.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>