a.engels@xxxxxxx wrote: > If I use ext3 on top of a file backed loop device, I understand that the > consistency is in danger because writes are reordered of the underlying fs. > What I dont understand is the claim, that ext3 (top) <-> loop-aes <-> ext3 > (underlying with data=ordered or data=journal) should work. Why is the > assumption correct that the underlying ext3 preserves the same write order > of the ext3 on top? Some older loop-AES README files said that ext3 -> loop -> file-on-ext3 (data=ordered or data=journal) should work. Newer versions of README advise to not use file backed loops at all. File backed loops may work under certain circumstances, but it is better to avoid using them. > I am not worried about the file transfer to the backup machines. I dont > fully (actually not at all) trust the backup machines. I cant restrict > physical access to these machines and I am not the only one who has root on > them. Theoretically, a secure whole disk encryption should deliver enought > security even if the image is world readable, right? loop-AES is still vulnerable to attacks that involve trojaning utilities used to mount and use encrypted file systems (losetup, mount, gpg, kernel+modules, init scripts, and other suid root programs). loop-AES is also vulnerable to attacker modifying ciphertext; ciphertext is not authenticated and attacker tampered ciphertext will decrypt without detection. It is possible for attacker to revert whole file system ciphertext to some earlier version (if attacker had access and saved old ciphertext). Also each individual 512 byte sector can be reverted to old state. It is possible to copy ciphertext of known plaintext to other sector, and only first 16 bytes of copied ciphertext will decrypt incorrectly. My point is: secure software crypto in rooted or otherwise insecure box is impossible to achieve. > Another question: how does loop-aes react on bad blocks? I/O errors of underlying device are reported to file system on top of loop device. It is up to file system to report I/O errors to applications. Errors resulting from damaged ciphertext (no I/O error detected by underlying device) stay in same 512 byte block where damaged ciphertext is and errors will not propagate to other sectors. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
