i agree with the blocksize... i did think that i might have to force an
inode size to match the encryption size... or vice versa... (not sure if i
mean inode size here... still learning!!!)
the benefit of encrypting the the inodes is that everything on the
filesystem is encrypted... directorynames, filenames, the data in the
files... all for the price of encrypting the data at such a low level... (i
think???)
i dont like loopback encryption... i guess it is mostly personal (or lack of
knowledge)... but why attach encryption to a filesystem, would it not be
faster safer to embed the security into the filesystem...
steve...
-----Original Message-----
From: Andi Kleen
To: Steve Lord
Cc: Stephen Brewer; 'linux-xfs@xxxxxxxxxxx'
Sent: 7/5/01 6:00 PM
Subject: Re: encryption
On Thu, Jul 05, 2001 at 10:41:09AM -0500, Steve Lord wrote:
> If you have an encryption algorithm which does not change the size of
> the information, i.e. the encrypted data takes the same number of
> bytes as the non-encrypted data, then things are a lot easier. My
> memory of encryption says that this is not normally the case unless
> you are using very basic algorithms which are easy to crack.
> Once your algorithm changes the size of data it gets really hard to
> deal with managing disk layout.
If your data is a multiply of the block cipher blocksize (normally 16
bytes on a
AES style cipher or 8 bytes for DES) then the data size doesn't change.
If it's not a multiple of a good block cipher size an stream cipher
could
be also used, which does not operate in fixed blocks (at least not
blocks
bigger than a byte); but it requires more complicated key management
because
you cannot reuse the key for two different disk blocks.
As far as I can see all data structures in XFS on disk should be
multiplies
of 16 bytes.
BTW; Linux already has an existing encryption interface for file systems
via the loopback device; unfortunately the existing encryption modules
all have various drawbacks and problems. This works only per block
device
of course and it is relatively hard to store any metadata which means
e.g.
it is impossible to check the user's password.
An XFS based per file encryption mechanism would be definitely
interesting.
One problem is how to specify the password per file without having to
patch all applications.
I'm not sure why the inodes should be encrypted though (they really do
not
contain much sensitive data and encrypted inodes would make backup
really
hard); wouldn't it make more sense to encrypt directories and file data
only?
>
> > has anybody thought about this before???
> >
> > i have found a method called 'xfs_iflush_int' does all writing to
the hard
> > disk go through here, or are there many places in the code that
would need
> > to be modified for decrypting/encrypting???
>
> The tricky part is the journal, do you want to protect the journal as
well?
> Inodes written to the journal in a different format from the on disk
format.
And the swap partition needs also be protected; otherwise your precious
data
could easily end up clear text there.
-Andi
|