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

[Zenny]

Thanks Matt.

On 7/10/13, Matthew Dillon <dillon at apollo.backplane.com> wrote:
>
> :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.

Look forward to. ;-)

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

Impressive to learn that there would be entry space with 255 conf
slots against LUKS' 8.


>
> 					-Matt
> 					Matthew Dillon
> 					<dillon at backplane.com>
>