Messages in this thread | | | Date | Mon, 6 Sep 1999 17:02:28 +0200 | From | Alexander Kjeldaas <> | Subject | Re: loop.c transfer module api |
| |
On Sat, Sep 04, 1999 at 04:26:35AM -0500, kernel@draper.net wrote: > 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. >
This is the reason I chose to have the relative block numbers be an option. However, I'm not sure how much the security is improved by having absolute block numbers. The following is the attack I'm basing my assumptions on. There are probably other attacks that I am unaware of though:
Some TLA agency wants to break Linux ext2 file-systems. They know each file-system start with a common header. Thus, they encrypt the starting block of a linux file-system with 2^n different keys and put them in a large table [ n is the number of bits in the cipher's key]. Then, to crack a file-system, they simply look up the first block of the loop-device in their precalculated array and get the key.
But the above attack can be circumvented by using a cipher with a longer key. If you use a 128-bit key and the entropy of your passphrase is indeed 128 bit, then building the table above seems to require _a lot_ of disk-space, even if they can do certain optimizations that only require them to store 2^90 or so blocks.
Regarding the increased security given by using the absolute block number I think that in some cases it is very low. For instance in the case where you use a whole partition, chances are that you have partitioned your HD on a MB boundary or a cylinder boundary. With some statistics I doubt the block number gives you more than 10bits of random data. For a file it might be more but to me it still seems that increasing the key-length of the cipher you're using is a lot easier than not being able to take backup of your encrypted files.
> 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". >
Do you know of other attacks than the one mentioned above?
astor
- 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/
| |