Exactly. I also wrote a README file which accompanied the
two ciphers which explains this. From the README
"Both algorithms use CBC mode to encrypt a single sector (512
Bytes). So identical sectors produce identical crypted sectors,
which is not ideal. A solution would be to use the number of the
sector in the cryption algorithm, but this would require some
interface changes to loop.c and since I'm not the maintainer I
didn't want to do that."
The problem is that the sector number of the first sector,
isn't passed to the transfer functions. It's no problem to change that,
but this IS an interface change.
PS: By The Way, who is the maintainer of the loop-device at the
moment ? (Is there anyone ?)
I was the original author of the loop-device. After it was done, I
perceived that it would be useful if it could have crypto support, but
given that I lived on the wrong side of the Crypto Iron Curtain, I
turned over maintenance of the loop device to Werner Almesburger (the
author of LILO, and more importantly, citizen of Switzerland :-) with
the suggestion that adding crypto hooks to the loop device might be a
cool thing to do. (Remember, this was back while Linus was still living
on free soil, so the assumption was that Werner could add the crypto
code, and it could get folded into the main kernel sources and be
distributed out of Finland.)
Over the years, apparently Werner lost interest in the loop device
(probably busy with lots of other projects), and the loop device has
drifted, with random people adding patches as necessary to fix various
crypto bugs, etc.
So the answer is, as near as I can tell, no one is currently actively
maintaining the loop device. If someone who is willing to put in work
to spiff it up, I for one would say it is a good thing, and I would
certainly give them my moral support (for whatever that is worth).
My one caution is the obvious observation that as people fix some of the
cryptographic shortcomings in the current loop device, that folks
remember to maintain at least some amount of backwards compatibility for
folks who need to use both old and new kernels. (Some conversion tools
to convert an old-style encrypted filesystem to a new-style encrypted
filesystem would also be cool, but some people may wish to continue
using the old-style format for compatibility reasons.)
- Ted
-
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/