>>>>> "david" == David Woodhouse <dwmw2@infradead.org> writes: david> On Wed, 2003-02-19 at 14:54, Juan Quintela wrote (re encryption): >> If you do it at the filesystem layer you: >> a- leave the filesystem structure (i.e. names) unencrypted david> Why would you want to do that? It's not really an invariant property of david> encryption-capable file systems, surely? You can crypt the names if you david> want to. Some paranoid security person, don't want an attacker to know what file to atack :p I.e. that the attacker is able to read a name like: here_is_where_we_store_security_passworkds.txt And they have the same problem for only giving them the filesystem structure :( >> b- you just don't care if you are not able to recover things at fsck >> time :( david> Likewise. It might be decreed that file sizes and directory tree david> structure are an acceptable leak of information and hence you can have a david> fsck which just doesn't grok either filenames, permissions or data -- or david> you might decide that's not an acceptable leak, and require the key in david> order to fsck it. You need the key in order to fsck a file system on an david> encrypted block device _anyway_, right? Yep, problem is that you have a corrupted filesystem, you know the key, but you don't know what kind of information has this block. If the block is encrypted, bets are basically off :( you can't apply easily heuristics :( Was that blocked ever used, and then its value is encrypted/have nothing interesting? >> c- you are really clever and finds a way to encrypt all the filesystem >> and recovering from a crash david> Parse error. >> Apart from that, doing it at the block layer should be much, much >> easier :) david> Filesystems are hard. Let's go shopping :) david> Doing redundancy at the block layer is much much easier too. That david> doesn't necessarily make it not suck when a raid rebuild is pointlessly david> copying blocks which aren't actually _referenced_ by the file system, david> because it doesn't have the knowledge about the layout that the file david> system does. I think that the only reason why encryption at the filesystem level makes sense is when you want to only encrypt _some_ files, but at that point, you can also encrypt by hand them with some script/similar :( About that things are easier at the filesystem level than at the block device, yes, they exist, another example is snapshots. Snapshots at the block level are easy to do, they just use a lot of disk space. At the filesystem level, they are more eficient (duplicated info is minimal), but you need to be very, very careful to implement them at the filesystem level. At the block level it is _almost_ trivial (at least when you compare it with an implementation at the filesystem level). It just happens that from my point of view, encryption is a lot easier and more secure done at the Block layer level. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
