Messages in this thread |  | | Date | Sat, 14 Oct 2000 14:43:08 +0000 | From | Ingo Rohloff <> | Subject | Re: A patch to loop.c for better cryption support |
| |
> _I_ can use my approach, but not yours, to bring my already existing > crypted fs into the new state. The losetup option to set the encryption > chunk size is used only once for each fs, but at that one time you can > do: Ok, I understand what you mean.
> Q> losetup -e blowfish --use-fs-blocksize \ > /dev/loop0 cryptfile > Q> losetup -e blowfish /dev/loop1 cryptfile > Q> dd if=/dev/loop0 of=/dev/loop1 bs=4k > Q> losetup -d /dev/loop1 > Q> losetup -d /dev/loop0 > (Replace bs=4k" with the blocksize of your underlying filesystem). I.e., The "bs=4k" shouldn't be necessary at all. Because this would imply that the correct behaviour of the encryption is dependent on the blocksize in which the data is requested by an outer read() call. If this is really the case something is broken. (AFAIK the current behaviour is broken, because it exactly relies on this fact.)
> I can convert the stuff _in place_ (it actually works, anyone please > complain loudly if it shouldn't) even when my 'cryptfile' is /dev/hdax > and I don't have sizeof(/dev/hdax) space left on my hard drives. This could be dangerous. I'm not sure that the kernel handles this kind of concurrent access to the same encrypted blocks correctly. (I admit, that I think it should work but it still might be dangerous...)
> Whether you use a signed or unsigned int for the sector address does not > affect the encryption at all. So I don't see your point here... Well you said that my patch was a shot from the hip and complained that I declared IV as "int" even if "request.sector" was declared as "unsigned int" :-).
> much the same idea as you). In fact, your approach could well be default > way of encryption, but there should be a way to set the block size. At > least to the block size of the underlying (call it compatibility mode or > so). Yet, I think that there may be some clever uses for a completely > free choice of the encryption chunk size, down to one cipher block size > and up to the underlying's block size.
To build in a backward compatible way is OK, but I'm still concerned about bigger blocksizes than sectors: The reason I wanted sectors is, that it seems that the smallest chunk of data that can be requested from the outside is one sector, which means 512 bytes. (I'm not sure if this is correct, but because ReiserFS works with the sector approach I guess it has to be true.) It should be no problem to implement smaller encryption chunk sizes. On the other hand, if we use more than one sector, we might run into the problem that some utility which accesses the loop device on a more direct way ( - bypasses the FS - ) uses sectors as access unit and NOT blocks.
In this case we would have to ensure that the accesses are always aligned to the chosen blocksize and this makes things more complicated. (It is possible though...)
> IV generation is what I am worried about. > There is a paper about why it is a bad idea to use > sequence numbers for CBC IV's. I just have to find the reference to it. Does this mean sequence as in 0,1,2,3,4 ... or does this mean any pre-calculate-able sequence ? In the former case we might just use a simple one way hash-function over the requested sector number.
In the latter case, we might be able to use a message digest algorithm which includes the sector number and part of the key. (Both approaches slow the encryption further down, but for security concerned people this doesn't matter...)
> PS: Ingo, it's vger.kernel.org, not vger.linux.org. Yes I found that out... I just imagined that I sent my first message to vger.linux.org, don't ask me why :-).
so long Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |