I'm looking for a way to store an encrypted filesystem on rsync.net which can be mounted and used by multiple clients concurrently - I've considered and experimented with many different ideas, including:

  • duplicity (recommended by rsync.net)
  • truecrypt
  • dm_crypt/LUKS
  • git
  • RAID1

but all of them are leading me to what looks like a fundamental theoretical problem: a filesystem with concurrent access needs someone to manage it, and who's going to manage it if I can't trust the server? Or refuse on principle to trust the server? There would need to be some trusted entity communicating with every client and making decisions to keep the filesystem and/or block device consistent, right?

Is my understanding correct, or is there any way of achieving what I'm trying to do? Thanks.

  • On a theoretical level its certainly possible, just don't let the server have access to any of the unencrpyted information. Just have it send the data in track 3, sector 2, cluster 15 to user 2, and then let user 2 decrypt it, and then make a new request. I don't have to trust anyone for that. – soandos Jul 26 '11 at 4:31

What are the users doing with the server? If it's only for file storage and sync, you could set up a way for each of them to have an encrypted container (e.g. TrueCrypt, LUKS) with their own encrypted password or keyfile. Then when syncing, the rsync can pick up the raw byte changes in the container even though it's encrypted. That way the server doesn't get to access the encryption key.

  • Only problem with that is that incremental diffs aren't going to be effective because of the Avalanche Effect. – Andrew Moss Aug 11 '11 at 13:56
  • The avalanche effect won't be a big deal because the cascading stops at the sector boundary (normally 512 bytes) in the virtual filesystem within the container. The changes don't propagate to the whole container. – Mike Rowave Aug 11 '11 at 15:35
  • Granted, a single-byte change in the plain text could cause several kilobytes to be updated, but that's largely because of meta data (and journaling, if applicable) caused by the file change (and the resulting encryption cascading of the meta updates). For larger file changes, the overhead due to encryption cascading and metadata will be tiny compared to the size of the change itself. – Mike Rowave Aug 11 '11 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.