Re: partially encrypted filesystem

[Richard B. Johnson]

On Wed, 3 Dec 2003, Kallol Biswas wrote:

>
> Hello,
>       We have a requirement that a filesystem has to support
> encryption based on some policy. The filesystem also should be able
> to store data in non-encrypted form. A search on web shows a few
> encrypted filesystems like "Crypto" from Suse Linux, but we need a
> system  where encryption will be a choice per file. We have a hardware
> controller to apply encryption algorithm. If a filesystem provides hooks
> to use a hardware controller to do the encryption work then the cpu can
> be freed from doing the extra work.
>
> Any comment on this?
>
> Kallol
> NucleoDyne Systems.
> nucleon@xxxxxxxxxxxxxx
> 408-718-8164

I think you just need your application to encrypt data where needed.
Or to read/write to an encrypted file-system which always encrypts.
You really don't want policy inside the kernel.

Let's say you decided to ignore me and do it anyway. The file-systems
are a bunch of inodes. Every time you want to read or write one, something
has to decide if it's encrypted and, if it is, how to encrypt or
decrypt it. Even the length of the required read or write becomes
dependent upon the type of encryption being used. Surely you don't
want to use an algorithm where a N-byte string gets encoded into a
N-byte string because to do so gives away the length, from which
one can derive other aspects, resulting in discovering the true content.
So, you need variable-length inodes --- what a mess. The result
would be one of the slowest file-systems you could devise.

Encrypted file-systems, where you encrypt everything that goes
on the media work. Making something that could be either/or,
while possible, is not likely going to be very satisfying.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/