Meta information:
This mail proposes a fix for:
must-fix list item "drivers/block/loop.c" and
should-fix list item "drivers/block/cryptoloop"
Content:
loop.c is broken. It's broken since 2.4. In particular the initial vector
calculation which every cryptographic loop transformation uses is broken.
What's the problem you might ask.. It's that that the IV calculation is
based on the logical block sector of the block device. Just think of what
happends if you move your image to another device with a different block
size..
Correct! The IV metric changes and everyone who knows what's CBC
encryption will correctly conclude: you can't read your image.
That's bad. And that's the reason why every project which provides you with
encryption via loop.c will also provide you with a patch for this broken
loop.c behavior.
The fix is quite simple. Just switch to a fixed IV metric. Which is: the
smallest granulity -> fixed 512-byte and kerneli.org's cryptoloop as well as
Jari's loop-AES do exactly that.
These two packages are the only facilities I'm aware of that provides
harddisc encryption for the 2.4. kernel. However marcello refused to switch
the IV metric for 2.4. because it will - yes that's correct - break any
image which has been created with a IV-sensitiv loop transformation..
..BUT except for cryptoloop and loop-AES there are no such loop
transformation modules! And those two projects have already fixed this
issue. So we're providing backward compatiblity for nothing here. No user
base could ever benefit from this backward compatiblity, since the only
reason the initial vector calculation is done is for crypto and every crypto
project out there already uses the 512-byte IV-metric.
So go for it. Fix it before 2.6.x is out and we're stuck with this crap
again.
http://bugzilla.kernel.org/show_bug.cgi?id=192
Just apply the patch.
If this bug is fixed, we can go ahead and add cryptoloop which is ready and
tested.
Regards, Clemens
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:32 EST