http://reagle.org/joseph/blog/technology/loop-aes-and-remote-mounts
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 days 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
yet.
Given the way it is currently written, the remote crypto partition is
actually mounted on the remote host. That means root on the remote host
could look at the unencrypted files if he wished to abuse the permissions.
In the past, I was root on the remote machine so I had little to worry
about. Yet, I could re-implement this 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
plaintext files even when I do. 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 a 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 have very slow access times since it's over the network.