I have recently set up a couple of my computers to run with
an encrypted loopback root filesystem (with a small unencrypted
/boot partition that does some fancy initial ramdisk machinations).
I have done this both with loop-AES and with the kerneli patches,
once I saw Jari Ruusu's comment about the problem with cryptoapi
being that its initial value calcuations are dependent on block size.
I believe that Jari addresses this initial value problem
in his loop-AES code with the following change to drivers/block/loop.c:
@@ -181,7 +273,7 @@
len = bh->b_size;
data = bh->b_data;
while (len > 0) {
- int IV = index * (PAGE_CACHE_SIZE/bsize) + offset/bsize;
+ int IV = index * (PAGE_CACHE_SIZE >> 9) + (offset >> 9);
size = PAGE_CACHE_SIZE - offset;
if (size > len)
...and a few other places with essentially the same change.
The problem with Jari's formula is that it will give different
initial values on architectures with a different PAGE_CACHE_SIZE.
I propose that we adopt a formula of the initial value being
the low 32 bits of: (byte_offset + (byte_offset>>32)).
In other words, the calculation in the above patch would
become something like this, which I am just typing in without testing:
u32 IV = (index>>PAGE_CACHE_SHIFT) + offset +
(index << (32-PAGE_CACHE_SHIFT));
I would really like to see this standardized quickly, because
changing formats would be a really pain once a lot of people start
running completely encrypted systems.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@xxxxxxxxxxxxx \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
