lkml.org 
[lkml]   [2000]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A patch to loop.c for better cryption support
> So, the only provision that needs to be made to ensure backwards
> compatibility (both with the kerneli patch and other modules that still
> use absolute block numbers) is a way to switch between the new approach
> and the old, defaulting to the new. The easiest way to do this, IMO, is
> to allocate a new field 'encryption_chunk_size' or so from the set of
> reserved words in struct loop_info. One might even get away with a
> single bit, indicating whether to use 512 byte blocks or underlying
> blocks as encryption chunks. Maybe lo_flags could be used when it
> becomes allowed to set the single bit LO_FLAGS_USE_512_BYTE_CHUNKS or
> so. Then teach losetup to set this bit unless instructed not to.

Yes that's the start.
I have to study loop.c more intensivly, because I think
I found at least two more trap doors.
(It's amazing that it works at all :-) )

Look at the line

if (size > len)
size = len

This seems to be horrible wrong... A CBC chain always has
to decrypt/encrypt a whole block otherwise the data my
be irrecoverable. (With the sector approach it works, because
len is sectors << 9 ...)

And also

block = current_request->sector / (blksize >> 9);
offset = (current_request->sector % (blksize >> 9)) << 9;


The whole operation will go wrong if offset != 0 .

so long
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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