Ingo Rohloff wrote:
>
<snip>
> > First: This breaks backward-compatibility.
> Right, (I mentioned this), but the backward-compatible
> way means:
>
Don't confuse the backwards-compatible way with the current (broken, of
course) way of doing things. It is right that the _current_ approach of
using the blocks of the underlying as encryption units has all the
problems that you describe. Yet, the fix that I suggested is clean and
works exactly as what you want to do. There is only one difference:
_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:
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.,
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.
<snip>
> BUT: "unsigned int" and "int" have the same bit size right ?
> The crypto algorithms only care about the bits not the
> signedness (and if they do, they only have to interpret
> the IV as signed... no problem...)
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...
<snip>
Your approach is not so far away from what I suggested (which is a
simplification of what Alex suggested to me when I came up with pretty
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. 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.
Marc
PS: Ingo, it's vger.kernel.org, not vger.linux.org.
-- Marc Mutz <Marc@Mutz.com> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of PhysicsPGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
- 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:25 EST