On Wed, Dec 19, 2001 at 11:51:43AM +0100, Gisle S{lensminde wrote:
> Yes, this is a problem with loopback crypto. The problem is that the
> loopback interface assume that it's length preserving,
can you explain the rationnal behind such assumption ?
> and that make
> insertion of a MAC difficult. Calculating a MAC at mount/unmount will
> except taking long time, also fail to differ between tampering and
> a power failure. This may make the MAC useless in a security perspective.
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.
> Power failures is so much more common than attacks, that user will ignore
> it when an attack comes. A cluster level MAC will not be length
> preserving, and that will be a problem with loopback. Well, other with
> more in depth knowledge of the block device part of the kernel should
> comment on this. My proposal is that a secure file system is the right way
> to go. In a file system, meta data like MACs is no problem, and features
> like per-user encryption can be inserted.
>
> A furter note:
>
> An attacker can do the following. If byte i in disk block Ck is
> modified, the the blocks from i and out is modified. if k = floor(i/8)
> then C0 .. Cn is replaced by C0 .. Ck-1 | Dk .. Dn, where D express the
> new cipher blocks. Reinserting Ck .. Cn can't be detected.
>
> This will also work if you get a collision between CBC blocks, like
> described earlier on this list. Then the data after the two cipher blocks
> can be exchanged.
i dont understand your note
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
