Loop-AES and Remote Mounts

2003-12-10T15:46:00Z

I tend to keep most of my files on encrypted partitions. Fortunately, this is easy to do now that the crypto loop devices are integrated into the Knoppix kernels (and even the mainline 2.4.22 kernel) and tools (e.g., losetup). To do a backup, I mount a local partition, and then use unison (a very fast update program) to send the changes to a partition on a remote host. A day's work takes less than a minute, sometimes seconds, to update over a decent connection.

sb.py is the script I wrote to mount the partitions locally and remotely (via pyexpect over SSH). Presently, the remote functionality is commented out since I don't have a couple of gigabytes of storage on a remote host anymore.

Given the way it is currently written, the remote crypto partition is actually mounted on the remote host, and unison then works its magic over SSH. That means root on the remote host could look at the unencrypted files if he wished to abuse the permissions specified for the mounted (unencrypted) partition. In the past, I was root on the remote machine so I had little to worry about.

However, I could re-implement this script such that the remote raw crypto loop-back file is actually available locally (via NFS or SAMBA) and I mount it locally. In this case, the remote host should never have access to the unencrypted files even when I do. Unfortunately, I'm unsure of the performance of doing a local mount of a remote crypto file system, and unison would probably be slower. A strength of unison is that when it's running over SSH looking for file changes, each host is running its own version of unison that is quickly examining a local file system and then the two versions compare notes. In the new scheme, one version of unison would be comparing two directories, one of which would mounted over a network and have slower access times associated with it.

Joseph Reagle

Loop-AES and Remote Mounts