From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: Hi Date: Wed, 19 Feb 2003 12:00:24 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030219170023.GB2827@delft.aura.cs.cmu.edu> References: <20030218150457.20101.qmail@webmail30.rediffmail.com> <20030218163422.GC1399@arthur.ubicom.tudelft.nl> <1045609648.18245.0.camel@imladris.demon.co.uk> <20030219153537.GB2516@arthur.ubicom.tudelft.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 3.36 #1 (Debian)) id 18lXa4-0000p4-00 for ; Wed, 19 Feb 2003 12:00:24 -0500 To: linux-fsdevel@vger.kernel.org Content-Disposition: inline In-Reply-To: <20030219153537.GB2516@arthur.ubicom.tudelft.nl> List-Id: linux-fsdevel.vger.kernel.org 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