[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    Re: Vulnerability in encrypted loop device for Linux
From:       Jerome Etienne <jme () off ! net>
Date:       2001-12-19 13:29:12
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]