[lkml]   [2000]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A patch to loop.c for better cryption support
[added cc: linux-crypto]

Ingo Rohloff wrote:
> Hi,
> First some explanation. Most cryption algorithms initialize
> the cryption process with some init values, called IV (by me :-).
> This means that two identical clear messages will give
> different encrypted messages, if different IVs are used.
> 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.
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.
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).

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

You may want to join (majordomo) if you want
to work on this.


Marc Mutz <>
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.084 / U:9.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site