i forgot to send this reply to the list...
On Wed, Dec 19, 2001 at 03:09:05PM +0100, Gisle S{lensminde wrote:
> My impression about the loopback interface, is that it is supposed to
> be a 1:1 mapping fom the raw disk to the loopback. The traditional
> use of the loopback interface (without encryption) have been used for
> such things as mounting cd images without burning it to a CD.
> Filesystems and other usages of disk partition may assume things
> about the underlaying media. It shoudn't but before I know that
> I'm a bit skeptical to breaking the 1:1 relationship present in
> the loopback interface. That's the reason for stating that I don't
> know too much about the block device part of the kernel. I tried
> to discuss potential problems. I Not having a block size divisible by
> 512 can make problems for many file systems, so the MAC should not
> be stored at the end of each block anyway.
>
> A block cluster approch would be preferable, since that don't require
> scanning the disk on every mount/unmount. What about a block containing
> a 128 bit HMAC-SHA1 of the preceding.
It is the choice of the implementors to decide where to put the
authentication result.
> > i disagree. as a user, i may know if my computer uncleanly umount
> > a partition (e.g. i was in front of it when it crashed).
> > so when i reboot it, i know it was a unclean mount and not a attack.
>
> My experience is that users don't know this, and that it should be taken
> into account when making cryptosystems.
my experience is different. even window users are aware that a computer
crash require to fsck it on reboot because they see it (scandisk/chkdsk)
on the screen while rebooting (here i take an example of window users
because they are on average less knowledgeable than unix ones, not
because of any religion war)
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
