Skip to contentSkip to conversation

Announce: cryptoapi-2.4.3 [aka international crypto (non-)patch]

DISCUSSION Herbert Valerio Riedel 3 participants 6 messages Apr 23, 2001 – Apr 26, 2001

lore
Share & tools
lore

Herbert Valerio Riedel

author
#0 lore raw

hello!

short version:
this is the international crypto patch, which is built outside of the kernel source tree. you don't even have to reboot (unless your kernel didn't have loop devices enabled, or some other unthought situation exists... :)

As a response to Jari's loop-AES crypto filter for the loop back device, which claims to be hassle free since no kernel modification is needed; I've repackaged the all known international crypto patch, which according to some people suffers from the need to patch the kernel in order to make use of it and thus may not be ever get into the kernel since there are still some countries where laws don't support an individuals need for privacy.

This (re)package has only one major drawback, crypto can only built as modules so far and it supports only kernel 2.4.3 and later so far...

If you are interested you can get it from

http://www.hvrlab.org/pub/crypto/cryptoapi-2.4.3-hvr4.tar.gz

...as usual, backup your data before playing around with it... :-)

ps: there is an optional patch against loop.[ch] contained, which fixes current IV calculation bugs and introduces a selectable sector based IV calculation mode.

greetings,

Signature · 2 lines
Herbert Valerio Riedel      /     Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142
#1 lore raw
Quoted 14 lines · Herbert Valerio Riedel

short version:
this is the international crypto patch, which is built outside of the kernel source tree. you don't even have to reboot (unless your kernel didn't have loop devices enabled, or some other unthought situation exists... :)

As a response to Jari's loop-AES crypto filter for the loop back device, which claims to be hassle free since no kernel modification is needed; I've repackaged the all known international crypto patch, which according to some people suffers from the need to patch the kernel in order to make use of it and thus may not be ever get into the kernel since there are still some countries where laws don't support an individuals need for privacy.

Quoted 2 lines

This (re)package has only one major drawback, crypto can only built as modules so far and it supports only kernel 2.4.3 and later so far...

linux-2.4.3-cryptoapi-hvr4/drivers/block/loop.c lines 270...279 after your kernel patch:

static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long offset, unsigned long size)

{
	char *kaddr;
	unsigned long count = desc->count;
	struct lo_read_data *p = (struct lo_read_data*)desc->buf;
	struct loop_device *lo = p->lo;
	unsigned long IV = loop_get_iv(lo, (page->index * PAGE_CACHE_SIZE + offset - lo->lo_offset) >> LO_IV_SECTOR_BITS);
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	if (size > count)
		size = count;

Have you tested that code with partitions or files that are larger than 4 gigs? On systems where int is 32 bits, that computation overflows.

If you want 512 byte based IV computation without modifying your kernel at all, you can use the loop.o module from my loop-AES package. I haven't tried using your modules based cryptoapi and my loop-AES drivers together, but I don't see any obvious reason why they couldn't be used simultaneously.

My loop-AES package is here:

    http://members.surfeu.fi/ce6c8edf/loop-AES-v1.1b.tar.bz2
    md5sum 61e521a383ce9a90c3f7b98bcf789813

Regards,
Jari Ruusu <[email protected]>

#2 lore raw

hi,

Quoted 14 lines · Jari Ruusu

linux-2.4.3-cryptoapi-hvr4/drivers/block/loop.c lines 270...279 after your kernel patch:

static int lo_read_actor(read_descriptor_t * desc, struct page *page, unsigned long offset, unsigned long size)

{
	char *kaddr;
	unsigned long count = desc->count;
	struct lo_read_data *p = (struct lo_read_data*)desc->buf;
	struct loop_device *lo = p->lo;
	unsigned long IV = loop_get_iv(lo, (page->index * PAGE_CACHE_SIZE + offset - lo->lo_offset) >> LO_IV_SECTOR_BITS);
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	if (size > count)
		size = count;
Quoted 2 lines

Have you tested that code with partitions or files that are larger than 4 gigs? On systems where int is 32 bits, that computation overflows.

you're right, I actually had it right in the first place, but stupidly rewrote it to overflow C:-)

it should have been more or less:

unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));

I'll be fixed in cryptoapi-2.4.3-hvr6 (see http://www.hvrlab.org/crypto/)

oh, and btw, it should only concern file backed loop's... block devices, as partitions, should have worked fine...

Quoted 4 lines

If you want 512 byte based IV computation without modifying your kernel at all, you can use the loop.o module from my loop-AES package. I haven't tried using your modules based cryptoapi and my loop-AES drivers together, but I don't see any obvious reason why they couldn't be used simultaneously.

erm... I've looked at your patch... you do just the same thing as I do, as it concerns 'changing the kernel'... but you do it in a 'static' way... I want it to be changeable at runtime... and letting the way open to add more IV calculation variants in the future, which every filter can choose among at initialization...

Quoted 2 lines
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

greetings,

Signature · 2 lines
Herbert Valerio Riedel      /     Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142
#3 lore raw
Quoted 11 lines · Herbert Valerio Riedel
Quoted 2 lines · Jari Ruusu

Have you tested that code with partitions or files that are larger than 4 gigs? On systems where int is 32 bits, that computation overflows.

you're right, I actually had it right in the first place, but stupidly rewrote it to overflow C:-)

it should have been more or less:

unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));

I hope not exactly like that. What happens when "lo->lo_offset" is larger than "offset". Oops. Besides, the + operator takes precedence over the >> operator on the third line.

Quoted 10 lines
Quoted 4 lines

If you want 512 byte based IV computation without modifying your kernel at all, you can use the loop.o module from my loop-AES package. I haven't tried using your modules based cryptoapi and my loop-AES drivers together, but I don't see any obvious reason why they couldn't be used simultaneously.

erm... I've looked at your patch... you do just the same thing as I do, as it concerns 'changing the kernel'... but you do it in a 'static' way... I want it to be changeable at runtime... and letting the way open to add more IV calculation variants in the future, which every filter can choose among at initialization...

Have you ever observed the sizes of the transfer requests? The sizes of transfer requests change on the fly (and I'm not not talking about the last partial block of a file). Meaning, any IV computation that depends on the block size of a filesystem, is broken and must die! We do not have an option here.

Just for the record, loop-AES package does 512 byte based IV and does not care about filesystem block size. loop-AES package does not change kernel sources and is almost immune to kernel source changes made by distro vendors. Look, here I'm building loop-AES on almost vanilla 2.2.19aa2.

# make LINUX_SOURCE=/usr/src/linux-2.2.19aa2
cd /usr/src/linux-2.2.19aa2 && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.2.19aa2'
make -C  /root/loop-AES-v1.1b CFLAGS="-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c aes-glue.c -o aes-glue.o
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.2.19aa2/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.2.diff || cp loop.c-2.2.original patched-loop.c
patching file `patched-loop.c'
patch -p0 -l < loop.c-2.2.diff
patching file `patched-loop.c'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.2.19aa2/block
cp -p loop.o /lib/modules/2.2.19aa2/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.2.19aa2'

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

Here I'm building loop-AES on 2.2.19aa2-bad where I intentionally changed loop.c in a way that makes the loop-AES patch fail, but Makefile has a working plan B.

# make LINUX_SOURCE=/usr/src/linux-2.2.19aa2-bad
cd /usr/src/linux-2.2.19aa2-bad && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.2.19aa2-bad'
make -C  /root/loop-AES-v1.1b CFLAGS="-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2-bad/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c aes-glue.c -o aes-glue.o
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2-bad/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.2.19aa2-bad/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.2.diff || cp loop.c-2.2.original patched-loop.c
patching file `patched-loop.c'
Hunk #1 FAILED at 256.
1 out of 2 hunks FAILED -- saving rejects to patched-loop.c.rej
patch -p0 -l < loop.c-2.2.diff
patching file `patched-loop.c'
cc -D__KERNEL__ -I/usr/src/linux-2.2.19aa2-bad/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.2.19aa2/block
cp -p loop.o /lib/modules/2.2.19aa2/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.2.19aa2-bad'

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

Here I'm building loop-AES on vanilla 2.4.3-ac14.

# make LINUX_SOURCE=/usr/src/linux-2.4.3-ac14
cd /usr/src/linux-2.4.3-ac14 && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.4.3-ac14'
make -C  /root/loop-AES-v1.1b CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c aes-glue.c -o aes-glue.o
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.4.3-ac14/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.4.diff || cp loop.c-2.4.original patched-loop.c
patching file `patched-loop.c'
patch -p0 -l < loop.c-2.4.diff
patching file `patched-loop.c'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.4.3-ac14/block
cp -p loop.o /lib/modules/2.4.3-ac14/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.4.3-ac14'

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

Here I'm building loop-AES on 2.4.3-ac14-hvr5 with your kernel patch cryptoapi-2.4.3-hvr5/doc/loop-iv-2.4.3.patch applied, which makes the loop-AES patch fail, but Makefile has a working plan B.

# make LINUX_SOURCE=/usr/src/linux-2.4.3-ac14-hvr5
cd /usr/src/linux-2.4.3-ac14-hvr5 && make SUBDIRS=/root/loop-AES-v1.1b modules
make[1]: Entering directory `/usr/src/linux-2.4.3-ac14-hvr5'
make -C  /root/loop-AES-v1.1b CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE" MAKING_MODULES=1 modules
make[2]: Entering directory `/root/loop-AES-v1.1b'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c aes-glue.c -o aes-glue.o
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -c rijndael.c -o rijndael.o
rm -f patched-loop.c
cp /usr/src/linux-2.4.3-ac14-hvr5/drivers/block/loop.c patched-loop.c
patch -p0 -l --dry-run < loop.c-2.4.diff || cp loop.c-2.4.original patched-loop.c
patching file `patched-loop.c'
Hunk #1 FAILED at 181.
Hunk #2 FAILED at 232.
Hunk #3 FAILED at 466.
Hunk #4 succeeded at 519 (offset 17 lines).
Hunk #5 succeeded at 1000 (offset 1 line).
Hunk #6 succeeded at 1030 (offset 17 lines).
3 out of 6 hunks FAILED -- saving rejects to patched-loop.c.rej
patch -p0 -l < loop.c-2.4.diff
patching file `patched-loop.c'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14-hvr5/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DEXPORT_SYMTAB -c patched-loop.c -o patched-loop.o
ld -m elf_i386 -r patched-loop.o aes-glue.o rijndael.o -o loop.o
mkdir -p /lib/modules/2.4.3-ac14/block
cp -p loop.o /lib/modules/2.4.3-ac14/block
depmod
sync
make[2]: Leaving directory `/root/loop-AES-v1.1b'
make[1]: Leaving directory `/usr/src/linux-2.4.3-ac14-hvr5'

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

Regards,
Jari Ruusu <[email protected]>

#4 lore raw

hello!

Quoted 10 lines · Jari Ruusu
Quoted 6 lines · Herbert Valerio Riedel

On Tue, 24 Apr 2001, Jari Ruusu wrote:
it should have been more or less:

unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset - lo->lo_offset) >> LO_IV_SECTOR_BITS));

I hope not exactly like that. What happens when "lo->lo_offset" is larger than "offset". Oops. Besides, the + operator takes precedence over the >> operator on the third line.

...you are right again :-)

do you have any objections about...

unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset >> LO_IV_SECTOR_BITS)
- (lo->lo_offset >> LO_IV_SECTOR_BITS));

...then? ;-)

the assumption is, offset % LO_IV_SECTOR_BITS == 0
this calculation may overflow anyway... for file sizes around terabytes or so I guess... but another thing is, that every IV calculation should overflow at the same boundary... since it's just an IV value...

(maybe that calculation should be done in a 64bit domain anyway)

Quoted 5 lines

Have you ever observed the sizes of the transfer requests? The sizes of transfer requests change on the fly (and I'm not not talking about the last partial block of a file). Meaning, any IV computation that depends on the block size of a filesystem, is broken and must die! We do not have an option here.

I know that issue, I've already pointed that out some time ago, but there are compatibility problems as well, at first I thought the international crypto patch was the only filter to make use of that IV, but then I learned there were a few others as well...
(btw, the int crypto patch had the compatibility option for absolute block numbers for quite some time too... just for the sake of compatibility...)

and btw, many people seem to be quite happy with their non-512 based IV encrypted volumes... so why forcing them to switch?

btw, depending on the filesystem using the loop device, and the underlying file or device, the transfer requests size may be constant... e.g. at 4k blocks... but other filesystems, such as XFS do have different sections with different blocksizes... they clearly break things...

breaking up transfers into 512 bytes _everytime_ isn't a solution either... it is unefficient, especially for filters not making use of the IV at all...

Quoted 4 lines

Just for the record, loop-AES package does 512 byte based IV and does not care about filesystem block size. loop-AES package does not change kernel sources and is almost immune to kernel source changes made by distro vendors. Look, here I'm building loop-AES on almost vanilla 2.2.19aa2.

:-)

what I'm trying to say, you just take the kernel's loop.c, patch it to do 512 byte IV calculation (and 512 byte requests) and requiring the user to load it... you actually require the user to not have the loop.c device compiled into the kernel... and when your loop module is loaded into the kernel the stock loop module can't be at the same time... it's an XOR solution...

[..build log...]

Quoted 3 lines

Here I'm building loop-AES on 2.2.19aa2-bad where I intentionally changed loop.c in a way that makes the loop-AES patch fail, but Makefile has a working plan B.

[..build log2..]

Quoted 5 lines

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

Here I'm building loop-AES on vanilla 2.4.3-ac14.

[...yet another build log...]

Quoted 6 lines

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

Here I'm building loop-AES on 2.4.3-ac14-hvr5 with your kernel patch cryptoapi-2.4.3-hvr5/doc/loop-iv-2.4.3.patch applied, which makes the loop-AES patch fail, but Makefile has a working plan B.

[...guess what...]

Quoted 1 line

Result: Working loop.o module with AES cipher built in, and 512 byte IV.

two different minds -- two different approaches :-)

greetings,

Signature · 2 lines
Herbert Valerio Riedel      /     Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142
#5 lore raw
Quoted 8 lines · Herbert Valerio Riedel

do you have any objections about...

unsigned long IV = loop_get_iv(lo,
page->index * (PAGE_CACHE_SIZE >> LO_IV_SECTOR_BITS)
+ (offset >> LO_IV_SECTOR_BITS)
- (lo->lo_offset >> LO_IV_SECTOR_BITS));

...then? ;-)

Looks fine.

Quoted 12 lines
Quoted 5 lines

Have you ever observed the sizes of the transfer requests? The sizes of transfer requests change on the fly (and I'm not not talking about the last partial block of a file). Meaning, any IV computation that depends on the block size of a filesystem, is broken and must die! We do not have an option here.

I know that issue, I've already pointed that out some time ago, but there are compatibility problems as well, at first I thought the international crypto patch was the only filter to make use of that IV, but then I learned there were a few others as well...
(btw, the int crypto patch had the compatibility option for absolute block numbers for quite some time too... just for the sake of compatibility...)

Quoted 2 lines

and btw, many people seem to be quite happy with their non-512 based IV encrypted volumes... so why forcing them to switch?

They are time bombs. Can you be sure that upper layers in the kernel won't pass a transfer size that is not same as filesystem block size? I have seen that happen. If you haven't, you have been lucky. I'd rather not depend on luck.

Quoted 8 lines

btw, depending on the filesystem using the loop device, and the underlying file or device, the transfer requests size may be constant... e.g. at 4k blocks... but other filesystems, such as XFS do have different sections with different blocksizes... they clearly break things...

breaking up transfers into 512 bytes _everytime_ isn't a solution either... it is unefficient, especially for filters not making use of the IV at all...

There is no point to limit transfers to 512 bytes. Transfer function just needs to increment the original IV and reinitialize the cipher block chaining process after every 512 bytes transferred.

Quoted 4 lines
Quoted 4 lines

Just for the record, loop-AES package does 512 byte based IV and does not care about filesystem block size. loop-AES package does not change kernel sources and is almost immune to kernel source changes made by distro vendors. Look, here I'm building loop-AES on almost vanilla 2.2.19aa2.

Quoted 8 lines

:-)

what I'm trying to say, you just take the kernel's loop.c, patch it to do 512 byte IV calculation (and 512 byte requests) and requiring the user to load it... you actually require the user to not have the loop.c device compiled into the kernel... and when your loop module is loaded into the kernel the stock loop module can't be at the same time... it's an XOR solution...

Transfer size is not altered, see previous comment. No need for user to load the loop.o module, kmod does that automatically if CONFIG_KMOD=y. Build instructions in a README file say that loop must be disabled the kernel config for this externally compiled loop.o to work at all.

Quoted 1 line

two different minds -- two different approaches :-)

Ok.

Regards,
Jari Ruusu <[email protected]>