After reading through the kerneli change logs recently, I see this
statement:
Added new config option for using relative block numbers instead
of absolute ones when calling the loop block device's transfer
function. This should fix the #1 issue with using loopback crypto
filesystems.
The #1 issue (I hope!) was that loopback crypto filesystems cannot be
relocated.
Perhaps it would be helpful to explain why I chose absolute rather
than relative block numbers in the loop.c transfer changes made in
2.1.130, and carried forward into the 2.2 and 2.3 kernels.
The answer is simple: a guaranteed uniquely seeded initial vector for
each and every block on the backing device.
Why? Relative block seeded IVs are more easily duplicated (either by
the user himself through poor operating practices, or by an opponent),
thus enabling identical ciphertext to occur in multiple looped filesystems
on the same device. Duplicated ciphertext is helpful to the analyst
seeking to recover plain text and/or key material.
The CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK (nice addition btw for those
who insist on relocatable looped filesystems) Configure.help text might
include a short caution:
The use of relative block numbers may increase your vulnerability to
certain methods of cryptanalysis.
Sadly "looped transformation/absolute block seeded IV" filesystems
cannot be relocated. We often must choose between "stronger security"
and "operational convenience".
Reed,
-
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/