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 -- Marc Mutz <Marc@xxxxxxxx> http://EncryptionHOWTO.sourceforge.net/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
