Re: Discussion of differences between loop-AES and cryptoapi in respectto the loop.c modifications...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Herbert Valerio Riedel wrote:
> what I'm not sure about, is the reason of the addition of
> 
>     if(S_ISREG(inode->i_mode)) bs = BLOCK_SIZE;
> 
> since BLOCK_SIZE is defined to be (1 << 10) in fs.h

File backed loop device on 4k block size ext2 filesystem:

debian:/root # dd if=/dev/zero of=file1 bs=1024 count=10
10+0 records in
10+0 records out
debian:/root # losetup /dev/loop0 file1
debian:/root # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
dd: /dev/loop0: No space left on device                   <=====ERROR=====
9+0 records in
8+0 records out
debian:/root # tune2fs -l /dev/hda1 2>&1| grep "Block size"
Block size:               4096
debian:/root # uname -a
Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown

Loop driver in kernel 2.4.5 is ok, loop driver in 2.4.6 is not.
 
> finally, code to initialize the aes module have been hardcoded into loop.c
> this is IMHO a rather static approach, since unflexible, if it wasn't for
> this one, the modified loop.c could be easily used as drop in replacament
> for the cryptoapi, but nevertheless it might be possible to use cryptoapi
> with minor adaptions with the loop-AES modified loop-AES' loop.o. I'll
> investigate this one a little bit more, this might finally allow for
> backporting the cryptoapi to 2.2 by making use of jari's 2.2
> modifications.

Your code uses loop_register_transfer(). I see no obvious reasons why
loop-AES' loop.o would prevent your code from registering cipher id 18
(LO_CRYPT_CRYPTOAPI). Only id 16 (LO_CRYPT_AES) is preregistered.

> *)  loop-AES' aes.c can be seen as specialized case (don't take me too
>     literal here please) of an AES cipher. whereas the cryptapi's loop
>     filter makes use of the cryptoapi framework to chose among the
>     available (not even required to be known in advance) cipher
>     algorithms.

loop-AES' aes.[ch] are as portable as code can be. They work in Linux
kernel, Linux userspace, FreeBSD, OpenBSD, just about anywhere. They can
also be easily tested against published test vectors in userspace.

Regards,
Jari Ruusu <jari.ruusu@xxxxxxxxxx>

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


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux