Re: partially encrypted filesystem

[bill davidsen]

In article <Pine.LNX.4.53.0312031627440.3725@chaos>,
Richard B. Johnson <root@xxxxxxxxxxxxxxxxxx> wrote:
| 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.

Well said. This isn't the way to do it as you say, although you could
add an O_CRYPTO flag to creat() if you really wanted to.


Crypto in the program is definitely the better solution.
-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-
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/