Ahh.. I see. I was thinking in the lines of creating one big loopback device that could then be "partitioned" using the offset and size parameters. I think it would be quite nice if there could be no visible parts outside the system. I have a feeling that creating loopback devices directly from the hda would expose how big they are, which is not desirable. Maybe this is true if you first encrypt the entire drive as well. losetup -e AES128 -K key.gpg -S <seed> -C 100 /dev/loop0 /dev/hda (Why does noone use AES256? Isn't that more secure? Is there a big speed bump?) losetup -o @32256-s 1003451904 /dev/loop1 /dev/loop0 losetup -o @1003484160 -s 1003451904 /dev/loop2/ /dev/loop0 losetup -o @2006936064 -s 5000937984 /dev/loop3/ /dev/loop0 I though something like the above. This might not be advisable though? On Sat, 02 Apr 2005 12:00:56 +0300 Jari Ruusu <jariruusu@xxxxxxxxxxxxxxxxxxxxx> wrote: > Gabriel Jägenstedt wrote: > > Could I just ask why you gave different keys for each device? > > Because that provides better protection against identical ciphertexts. > Identical ciphertexts using same encryption key are bad because they > leak information. > > When sector data is encrypted or decrypted, position information > within a partition or device is used in IV computation and in > multi-key mode to also to select the encryption key. This provides > reasonable guarantee that when same data is written to more than one > sectors, ciphertexts will be different and attacker observing > ciphertexts can't find out what plaintext sectors contain identical > data. If same key file is used to encrypt more than one file system, > there is a danger that same data + same encryption key + same position > info will result in identical ciphertexts. > > Examples: > (A) losetup -e AES128 -K foo1.gpg /dev/loop1 /dev/hda1 > (B) losetup -e AES128 -K foo2.gpg /dev/loop2 /dev/hda2 > (C) losetup -e AES128 -K foo3.gpg /dev/loop3 /dev/hda3 > (D) losetup -e AES128 -K foo1.gpg -o @32256 -s 24643584 > /dev/loop1 /dev/hda (E) losetup -e AES128 -K foo2.gpg -o @24675840 > -s 5733020160 /dev/loop2 /dev/hda (F) losetup -e AES128 -K foo3.gpg -o > @5757696000 -s 526417920 /dev/loop3 /dev/hda (G) losetup -e AES128 -K > foo1.gpg -o 32256 -s 24643584 /dev/loop1 /dev/hda (H) losetup > -e AES128 -K foo2.gpg -o 24675840 -s 5733020160 /dev/loop2 /dev/hda > (I) losetup -e AES128 -K foo3.gpg -o 5757696000 -s 526417920 > /dev/loop3 /dev/hda > > In examples (A), (B), (C), (D), (E), and (F), first loop device sector > is encrypted using position info 0, second sector using position info > 512, third sector using position info 1024, and so on. In example (G) > first loop device sector is encrypted using position info 32256, > second sector using position info 32256+512, third sector using > position info 32256+1024, and so on. In example (H) first loop device > sector is encrypted using position info 24675840, second sector using > position info 24675840+512, third sector using position info > 24675840+1024, and so on. In example (I) first loop device sector is > encrypted using position info 5757696000, second sector using position > info 5757696000+512, third sector using position info 5757696000+1024, > and so on. > > Examples (A), (B), (C), (D), (E), and (F) must use different key files > to avoid identical ciphertexts. Examples (G), (H), and (I) can use > same key file because they never use same position info for IV > computation. > > > Oh and why is the first partition starting at sector 63? > > Because I losetup'ed file systems that were originally created as > partitions, but this time using partitionless full device. Most disk > partitioning software that uses MSDOS style partitions leaves first > track of first cylinder as unused. That is because the > Master-Boot-Record and partition table are in first sector of first > cylinder. > > -- > Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E > A9 DD > > - > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ > --- //gabriel - a true believer - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
