[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: loop_aes comments
Paul Rubin wrote:
> Hi, I'm a crypto implementer and want to run a crypto file system
> under Linux. I'm looking at loop_aes and I like its simple design and
> installation. I have a few comments about the cryptography.
[snip]
> - The method of generating AES CBC initialization vectors for file system
> blocks has some minor weaknesses:
> - the IV for a disk sector is simply the sector number, so if
> an attacker can copy your hard drive without your knowledge,
> then you change something (e.g. update a database field) and
> the attacker reads the disk again, he can tell the exact
> location (in AES blocks) of the first change in the sector.
> Colin Plumb has a clever method (used in Peter Gutmann's SFS)
> for computing an IV based on the whole contents of the sector:
>
> http://groups.google.com/groups?selm=7gicpf%24k21%241%40scream.auckland.ac.nz
If attacker can copy your hard drive without your knowledge, he can also
install trojan kernel -- it is 'game over' next time you mount that
encrypted partition. Loop encryption is supposed to protect data _after_
laptop theft or something like that where you won't see or use your laptop
any more.
Your point about about IV computation is still true. If I remember
correctly, PPDD does pre-encryption whitening, so attacker can only detect
which 512 byte sector was changed.
> - Since the IV is just an increasing integer sequence, it's not
> completely implausible that some file has sectors whose first
> AES blocks, when xor'd with their sector numbers, give the same
> IV. Suppose file A begins on sector 536 and its first four
> 32-bit words are 0 0 0 1. File B begins on sector 537 and its
> first four words are all zero. This means both files get the
> same IV and if their next several blocks are equal, the attacker
> can tell that. Colin's scheme helps that; encrypting the IV
> (with a different key than the FS key) before using it would help too.
True. If I could start from scratch without backward compatibility
worries, I would implement IV computing differently.
> - If you have two file systems encrypted with the same key, they
> get the same set of IV's and the attacker can find all the
> sectors that are pairwise equal (or have common prefixes) between
> the two FS's. In fact if any common prefixes exist, that tells
> the attacker that both encrypted FS's probably have the same key,
> also not a good thing.
Encrypting two filesystems with same seed (salt) is admin screwup. Just
don't do that.
> Using separate salts helps with this prob but is inconvenient if the
> FS's are removable (such as CD-roms). Maybe a mount option could
> be added to use the cd-rom volume ID as a salt, so the user
> doesn't have to type a salt at mount time. When writing the CD
> you'd generate a random string to use as the volume ID.
Now, how is the code able to read cd-rom volume ID from encrypted cd-rom? It
is chicken-and-egg problem.
Ugly workaround for this is to add 4096 byte offset to encryption and use
sha512 of first 4096 bytes as the seed. Something like this:
SUM=`head -c 4096 /dev/hda999 | sha512sum`
mount -t ext2 /dev/hda999 /mnt -o loop=/dev/loop0,encryption=AES128,offset=4096,pseed=${SUM},itercountk=100
Adding a 'pseedoffset=4096' mount option that does that automatically is not
impossible. Just send a patch, or ask me to do it.
> I also have a question: suppose I have a normal ext3 file system on a
> partition. Can I unmount it, encrypt it in place with aespipe, and
> then mount it through the loopback fs? I don't have another free
> partition to transfer to.
Yes.
Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/