> _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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:27 EST