hello! On Thu, 2002-03-14 at 23:57, Jari Ruusu wrote: > Andrea Arcangeli wrote: > > Only in 2.4.19pre3aa2: 00_loop-IV-API-hvr-1 > > > > Make the IV API not to be in function of the blkdev > > of the underlying fs, so you can copy your cryptoloop > > around without risking to lose data. This breaks the > > on-disk format of some encrypted transfer module though, > > if you don't like it please discuss it here in CC with > > Herbert Valerio Riedel <hvr@hvrlab.org>, the patch > > is from him. I think writing a converter in place of > > the loop data would be the preferred solution if needed. It could > > be done in a way to link transparently with the source of > > the kernel modules. just as a side note to compatibility to the old IV metric; the patch I sent to andrea is quite minimal, it only changes the IV metric, and adds a few #define's to loop.h in order to recognize the IV metric when compiling filter modules against it; as to jari's patch, if the following def's were added, it can be used instead of my minimal patch... /* definitions for IV metric */ #define LOOP_IV_SECTOR_BITS 9 #define LOOP_IV_SECTOR_SIZE (1 << LOOP_IV_SECTOR_BITS) typedef int loop_iv_t; ...except maybe for when backward compatibility is needed. As it is a major concern to some of us to be able to convert their old iv-metric encrypted volumes to the new "atomic"-IV-metric, it can be usefull to be able to have both IV metrics available on the same system... one approach could be to losetup the concerned volume w/ an old loop.o v ersion and decipher the content on-the-fly by doing something like # set up the loop dev losetup -e cipher /dev/loop0 /dev/partition # make sure we got the right passphrase etc...; and also make sure the # kernel fs code set the right transfer-block-size... mount /dev/loop0 /mnt/tmp; umount /dev/loop0 # decrypt on-the-fly... dd if=/dev/loop0 of=/dev/partition ...now in theory we should have the unencrypted data lying in /dev/partition now we could replace the loop.o module by one feature the new IV metric, and just reverse the process.. so far ok... but some of us might want to decrypt and encrypt directly, w/o having to have some unencrypted (thus unprotected) data lying around for the meantime; so we might want to have 2 IV metrics available at the same time... this can either be done by cooperation from the loop.o module, i.e. some option for setting the IV size to calculate... _or_ it can be calculated by the filter module, by finding out what IV blocksize to assume, and then dividing the 512-IV-metric by some integral factor to reflect the old metric... the latter approach is possible w/ my patch, and has been implemented cryptoapi's cryptoloop filter through ioctl()... this relays on the IV-fix not modifying the transfer block size (if the blocks passed to the transfer filter should become smaller than the old metric's IV block size, we simply can't emulate the old metric...), but only the passed IV value... ps: just to make one thing clear (again), I don't care too much whether my loop-fix or jari's goes in; I primarily care for a fixed IV situation (including the above mentioned #define's/typedef) and if possible anyhow to allow for limited compatibility to the old metric... regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Attachment:
signature.asc
Description: This is a digitally signed message part
