Hi all,
I'm new to the list (but I've read a couple of months of the archives if
that counts.) Formerly I used the kerneli 2.4.3.1 patch, until some
unknown disaster recently ate my root fs. I had my 2.4.3 crypto modules
backed up -- on an encrypted loop file, of course. :) So I upgraded to
2.4.9 and stumbled upon HVR's work. Thanks, Herbert!
I read what's there about the IV_MODE_SECTOR issue, and I think I
understand it but am not sure. With this enabled, a loop file will use a
block size of 512 bytes for the cryptoapi, and a copy of a loop file
will work no matter what the block size of the media it is on, and of
the media where it was created. Without it, if you create an encrypted
loop file on an ext2fs with a 1024 block size, a copy of that file can
only be mounted if it is on media with an identical block size.
Is that it? Or is it the block size of the filesystem inside the loop
file which is significant? See, I am wanting to make some encrypted CD's
which of course I would prefer to be able to mount directly from the CD.
And I want them to be accessible in the future, of course, even if I'm
using ext9fs with 40MB blocks on my 900TB turbo-optic storage device.
(I'll still want to look at the pictures of my kids from AD 2001, even
when the CD-ROM format is insignificant and outdated.)
While I'm here, and rather than write another post, I'd like to address
some comments to Jari. I think your project is excellent! It does make
sense to have a different approach in a competing project. But as
someone else commented, I would prefer to see at least one other
algorithm available.
I'm no cryptographer nor mathematician, but ISTM that having only one
algorithm potentially helps an attacker, because there's only that one
to contend with. You can look at the system and see which project is in
use, and if it's Loop-AES you know with high probability that any large
incomprehensible file could be an AES loop container. But if its Crypto
API, you have to consider all the alternatives too. And in the crypto
world you have to think about the future: algorithms might be cracked,
computing power might make brute force attacks feasible.
I hope to see both projects do very well while maintaining the highest
possible cryptographic strength. Whose is "ahead" of the other doesn't
really interest me except insofar as one's advances might also help the
other project. In a competition like this, we're all on the same side:
the only real enemy is the one who might want to read our data.
Jari, I personally would be more interested in your project with the
choice of at least one other algorithm, and if it could coexist with
the kernel's loop driver. The latter issue would better fit in with your
project's vision; a user could perhaps carry removable media with a loop
file, and be able to access it on almost any machine. How about if it
could be done all in user space, even without root access? Then you
would have an important distinction from Crypto API!
Rob - /dev/rob0
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
