On Thu, Dec 21, 2000 at 02:01:19AM +0000, Al Snell wrote:
> On Tue, 19 Dec 2000, Manuel Bouyer wrote:
> 
> > I'm not sure this is the best, because you could have to encrypt/decrypt
> > to much data, which will hurt performances. You may also run in the
> > problem that the crypted data are biggers than the original.
> > A way to do this would be to write a layered filesystem that files, and
> > possibly files names in directory.
> 
> Very few cryptosystems have any affect whatsoever on the file sizes! It
> will be easy to just call a function on each 512-byte block as it goes
> to/from the disk... it'll add a few microseconds of latency to disk access
> and slightly increase the CPU usage during disk I/O, but since disk
> bandwidth is so low, I doubt it'll be significant unless the cypher is
> naff - and there are crypto algorithms that keep the security in a large
> key initialisation ("login") time, during which large look up tables are
> created, while the actual encryption/decryption runs very fast.

What are good choices for an algorithm that wouldn't be weakened by some
known plaintext patterns in the input? I'm thinking particularly of 
directories, though things like the superblock backups might provide
a telltale as well.

Identical blocks at 0 and 32 would give a good hint - and many portions
of the superblock's content could be guessed from the size of the 
partition etc...

Anything not block-based would avoid this - or at least anything 
without the same block size as the FS.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
If you don't spend energy getting what you want,
	You'll have to spend it dealing with what you get.
					      - Unknown