announce: linux-int-2.4.3.1-hvr3

[Herbert Valerio Riedel <hvr@gnu.org>]

hello,

*WARNING* experimental *WARNING*

...this patch (on top of the official international crypto
patch-int-2.4.3.1) fixes some problems I've been experiencing with
the IV calculation in loop.c, which have some annoying consequences; 
(say, you wanted to move around images among medias with
different block sizes, e.g. burn an file backed image to a cdrom, then
you'll surely have fun mounting directly that cdrom block device... 
but there are problems even creating the image from user space, and
then having the blocksize changed in kernel space by some filesystem
implementation... there were other issues too...)

the approach I've taken to 'fix' this comprises two changes,

1. using a base of 512 (aka sector size) for IV calculation, instead
of the former way, to take the actual blocksize of the underlying media.

2. breaking up the encoding of a buffer into 512 byte chunks (if
needed) and incrementing the IV in transfer_cryptoapi()

(3. returning -EINVAL if trying to setup an offset into the loop data
 % 512 != 0  -- since that would break... unless somebody completely
rewrites loop.c...)

as to the experimental-warning issued at the beginning of this mail,
as you may already have noticed, this changes will make your old
encrypted storages unusable, due to the new IV calculation...

http://www.hvrlab.org/pub/crypto/patch-int-2.4.3.1-hvr3.gz

PS: something not related to this patch, -- I've noticed SMP related
data corruption, I suspect having the IV unlocked in the shared cipher
context may lead to race conditions... (maybe the IV should be passed
on a per-call basis in order to avoid spinlocks...)

greetings,
--
Herbert Valerio Riedel      /     Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: AC2A CD57 A5C8 A1CB 0A18  DA95 CB0B DB23 60B6 16F5


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