Re: Hi

[Jan Harkes <jaharkes@cs.cmu.edu>]

On Wed, Feb 19, 2003 at 04:35:38PM +0100, Erik Mouw wrote:
> The way to solve this is to encrypt at the block level. In that way I
> can't even mount the filesystem when I don't have the correct key, so I
> can't get to the file metadata. Sure, I could guess you're using ext3,
> but that still leaves too many uncertainties (like directory layout and
> filesystem usage) for an attacker to be able to crack your key. A brute
> force attack will succeed (maybe not in the estimated lifetime of the
> universe), but it's a lot harder than a brute force known plain text
> attack.

It mostly adds a level of difficulty, you can try to break it based on
expected filesystem types and expected known values for these
filesystems. f.i. ext2 has a reserved inodes, on a relatively fresh
install there may be several blocks with only initialized inodes
scattered across the disk. Copies of the superblock. Unknown, but
identical plaintext at different locations on disk, this way you can
derive if there is some kind of permutation of the key based on the
block/offset within the disk.

MSDOS/VFAT or other filesystems without holes will have a lot of blocks
filled with zeros. And every filesystem has some redundancy which is
used during fsck, this redundancy is a possible point of attack.

The biggest disadvantage of a block level encryption is that you would
have one key for everything and all users can either access the
filesystem or not. With file level encryption each file can be encrypted
with a unique (per user or group) key.

Oh, and there is no reason for the filesystem to give you access to
pathnames or file attributes, directory data could be encrypted just as
well and accessible for specific users only.

Jan