Hi again,
Marc Mutz wrote:
> > The loop device supports different IVs;
> > the IVs are initilized with the requested block
> > number.
> > I believe a better way is to use the requested
> > sector number from CURRENT->sector.
> > Using this value should make the encryption and decryption
> > process completely independent from the underlying device.
> Two times no.
>
> First: This breaks backward-compatibility.
Right, (I mentioned this), but the backward-compatible
way means:
You might get problems over NFS using a backing file.
You get problems if you burn a backing file to a CD
(at least that's what it says in the FAQ),
or if you copy it to another partition with a different
file system (which handles blocks differently) or ...
Has anyone tried to use an encrypted backing file
on ReiserFS. I would be interested if it works
with the old patch set.
I even created an encrypted ReiserFS in a backing
file, which was hosted on an uncrypted ReiserFS.
(ReiserFS doesn't care about sector boundries, so
it is especially useful for testing in this
case.)
I bet that this won't work with the old approach.
(Even if this might be, because the cryption algorithms
don't care about block boundries too :-( )
I know it works with my approach because I tried
(even over NFS).
> Second: I don't know much of the block device handling
> in Linux, but what you produced seems like a quick
> shot. I can see this e.g. at the point where you
> declare 'sector' to be 'int' (7th hunk), whereas in
> include/linux/blkdev.h request.sector is declared
> _unsigned_ int.
Well ok, my fault.
BUT: "unsigned int" and "int" have the same bit size right ?
The crypto algorithms only care about the bits not the
signedness (and if they do, they only have to interpret
the IV as signed... no problem...)
> I don't know what request.sector is for loop
> devices (The block number of the underlying
> filesystem, if any? The hard sector number of the
> underlying blockdevice? Always the 512-byte-blocks
> number?), but if it is not the latter, i.e. always
> "position >> 9", you have just shifted the issue
> from one level (the fs block size) to another
> (whatever units sector is in).
No I haven't. Because as you can see from the source:
1. The CURRENT->sector is the requested sector of
the loop device, which has nothing (whatsoever) to do
with the underlying backing medium (it is even independent,
of using a backing file or device.)
2. It is ALWAYS assumed to be 512 bytes.
(This doesn't change, even if the blocksize of the backing
device is SMALLER than 512 bytes.)
You got it right, it is (position >> 9). But "position" means
requested position within the loop device, which is as I said
completely independent of the backing medium.
You can even have two DIFFERENT (using different passwords)
encrypted filesystems in the same backing file.
Both mounted at the same time.
(For example in a 2Mb file you can use the first MB
for the first FS and the second Mb for the second FS.)
you can do that like this:
dd if=/dev/zero of=crypt.tst bs=1024 count=2048
losetup -e twofish /dev/loop0 crypt.tst (give Password 1)
losetup -e twofish -o 1048576 /dev/loop1 crypt.tst (give Password 2)
mke2fs -b 1024 /dev/loop0 1024
mke2fs -b 1024 /dev/loop1 1024
mount /dev/loop0 /mnt1
mount /dev/loop1 /mnt2
BTW this is _tested_. It works. (And you can do it over NFS
And you can burn crypt.tst to a CD without any problems.)
Try this with the current approach... It won't work.
> The better solution (for 2.2. and 2.4; in 2.5 Andries Brouwer has
> something more clean in his mind, IIUHC) is to add a new field to struct
> loop_info to indicate the encryption chunk size and patch losetup/mount
> to set this to 512 by default and to the filesystem block size if asked
> to by some command line switch. This allows people to convert their
> stuff.
This makes things more complicated. (It also gives you more choices,
but I don't think that the choices are very useful. It only gives
you a higher chance of corrupting your data.)
Converting the stuff is not so difficult. Copy your encrypted
stuff to somewhere else (if you like use PGP to crypt it anyway).
Change kernel.
Remake filesystem on crypted medium.
Copy your stuff back.
> You may want to join linux-crypto@nl.linux.org (majordomo) if you want
> to work on this.
Ah thanks for the hint, I didn't know this mailing list.
I hope it is not in dutch ? If it is I apologize for posting in
english. (I can't speak dutch).
so long
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:24 EST