Hi Jari! > 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 just had another idea which would fit my needs: ext3 -> loop-aes -> software raid1 -> hda1,hdb1 + loop (without encryption) -> file on ext3 Each time I want to backup my data, I do a raidhotadd of the loop device. I wait until it is rebuild using the data from the partions hda1, hdb1. If the rebuild is finished, I create a consistent state of the file system by terminating samba and data base engines. I do a raidhotremove of the loop device and have a perfect snapshot. In case of restore, I would use the loop device to rebuild the partitions. Would this scenario work? > > > 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). Right, I just forgot to point out, that the images are of course not mounted on the backup servers. > 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. Nice, I havent thought of this possibility. Maybe one could store a md5 checksum of the crypto container inside the crypto container itself and check consistency when the fs is mounted. However, this would mean to read the entire crypto container at each mount. Adding checksums to each block (checksum also includes position of block) would be another way. - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
