Paul Rubin wrote: > 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. > > I don't think so, it's easy to see ways this could happen. Suppose > you have a file-backed loop_aes FS, and it's backed up periodically as > part of a regular system dump and the backup tapes are archived. Now > if the attacker gets hold of the series of backup tapes, he has a set > of snapshots of your FS that he can use that attack on. Yes, that leaks some information about which cipher block was the first one changed inside a 512 byte sector. But being able to detect which 512 byte sector was modified, is also information leak. Just less so. > Or if the > underlying file system is log structured (sectors never get > overwritten unless the whole disk is full, and file operations can be > rolled back), simply getting the hard drive would get all those > snapshots, without needing the tapes. If filesystem blocks are written to different sectors, they are encrypted with different IV. Your point was about detecting changes to same sector. > An attacker who actually accesses the hardware also might choose not > to install any trojans because it increases the chance of detection. > Maybe I boot my laptop from a USB flash disk that I keep in my pocket, > and it validates checksums on the hard drive before going interactive. > Or maybe he wants to install a hardware bug (keystroke recorder), but > he has to assume I check for those. Installing something like that in > a laptop may not be so easy anyway. Yes, USB or CDROM boot would be more secure. > 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. > > In that case, there's no need to mess with CBC mode or initialization > vectors. You could just use AES in counter mode over the whole > partition, or use RC4 keyed by a hash of the FS key and the sector > number. Even doing the hash RC4 key initialization on every sector, > it should still be much faster than AES, for reasonable sector sizes. IV + CBC reduce chances of identical cipherblocks. And identical cipherblocks leak information. > I really don't think any of those methods are safe though, even if > you're a device backed loopback FS. Suppose there's a modern IDE disk > drive underneath and it develops a soft error (i.e. correctable by > ECC) on some sector. The drive might very well remap that sector to a > spare sector completely invisibly to the OS or the user. Now if the > attacker gets two versions of the same sector, he can just xor them > together and get back the xor of the two plaintexts. xor trick works with CTR mode, but not with CBC mode. > CBC mode as currently implemented in loop_aes is somewhat better than > that, but I think Colin's scheme is better still. I never said Colin's wasn't better. I agree 100% with you. > 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. > > What's PPDD? I remember looking at the loop_aes code and didn't > notice any whitening (just plain CBC) but may have missed something. PPDD == Allan Latham's PPDD http://linux01.gwdg.de/~alatham/ppdd.html > True. If I could start from scratch without backward compatibility > worries, I would implement IV computing differently. > > There's already interchangeable block ciphers; might as well have an > alternative chaining mode. I have been considering that for more than a year now. Tricky part is doing it without creating (in)compatibility mess. Just look at SuSE twofish / kerneli.org twofish and their incompatible IV computing mess and you understand what I mean. > 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: > > Yeah, I guess that works, though it uses up a sector. (Why 4096 bytes? > I thought cd-rom had 2048 byte sectors). I'm trying to think if skipping > the sector has any other bad consequences--I guess not. 2048 sould work ok for cdrom. 4096 was just 'always safe' choice. > Otherwise there > are some further workarounds possible, since the beginning of an ISO9660 > file system appears to be arbitrary (mkisofs puts its own copyright notice > there) so a random string could be put there instead. Another chicken-and-egg problem. You can't encrypt before you know the seed. And if seed is sha512sum of some ciphertext.... Regards, Jari Ruusu <jari.ruusu@xxxxxxxxxx> - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
