lkml.org 
[lkml]   [1998]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kerneli blowfish/twofish compromised?
Hi Ingo and Astor,

On Sun, Nov 22, 1998 at 08:42:15PM +0000, rohloff@informatik.tu-muenchen.de wrote:

<snip>

> If you have a look at "loop.c" you can find the following line
> in do_lo_request(void):
>
> len = current_request->current_nr_sectors << 9;
>
> Data is always written and read in sectors, which means in 512 byte
> chunks. I think that it is possible to request single sectors, if
> you set the block size to 512 Bytes when the files system is
> created.
>
> You are correct again to state that the CBC mode depends on this. If
> it would be possible to read single bytes, then encryption would be
> impossible without an interface change.
> Even more CBC mode depends on the fact that the data is always read
> and written on 512 byte boundaries.

Is sectors relevant here? Assuming that one intends to mount a
filesystem over /dev/loopn, the block size is by design a fixed multiple
of sectors. That size is passed to the subordinate transfer functions by
loop.c and is the smallest chunk of data to be enciphered per transfer call.

>
> so long
> Ingo
>
> PS: By The Way, who is the maintainer of the loop-device at the
> moment ? (Is there anyone ?)

I wish I knew... I was hoping that Andrew Mileski would take it. I provided
a loop.c patch months ago to him (old loop API) which enabled his IDEA code
(along with with other changes) to operate in CBC mode with unique IV's per
block. I never saw it again. I think Andrew is busy doing other things as
his code in the International Patch is very dated (stills assumes the old
loop.c API) and his ftp site was gone last I checked.

At any rate, I have developed a patch that applies on top of the
International Kernel Patch (patch-int-2.1.129-3) and makes the following
changes:

1) loop.c is modified to provide the disk block number when invoking transfer
functions. That can then be used downstream to develop unique IVs.

To whomever the loop device driver maintainer is... do you want to review
this loop.c patch for possible inclusion in Linus' kernel tree? Linus,
feel free to jump in here anytime :)

2) loop_fish2.c is modified to derive a unique IV based on disk block number.
The IV is then used to initialize the vectors in the block_encrypt_CBC and
block_decrypt_CBC functions.

Btw, on my 2.1.129 system loop.c passes 1024 byte blocks to the transfer
functions (that is to be expected given the ext2fs defaults). I removed
the 0x1FF test with good results (no repeating patterns in ciphertext
and no clear text leakage).

3) Modified loop_blow.c, loop_serpent.c, and loop_cast.c transfer functions
to accept, but not exploit, the block number provided by loop.c.

It is tempting to release the patches to the world via the International
Kernel Patch... but the silly USA munitions laws worry me. I doubt that
minor patches to "outside of the USA" crypto constitutes a munition. On the
other hand, I believe that my government can persecute (not a mispelling) me
into oblivion even if I am right...

Adding Linux CBC with unique IVs by block support to the RC6, DFC and
MARS code also looks like fun. IS anyone in the USA or Canada interested in
such things? If so I will do it...

I guess people in the USA or Canada needing a twofish CBC encrypted
filesystem wth unique IV's per block, mounted over /dev/loop, should
contact me directly for the kernel patches.

Regards,
Reed H. Petty <rhp@draper.net>

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

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