Messages in this thread | | | Date | Sat, 4 Sep 1999 04:26:35 -0500 | From | kernel@draper ... | Subject | loop.c transfer module api |
| |
Hi Alexander,
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/
| |