Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

  • duplicity (recommended by
  • 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.

share|improve this question
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.

share|improve this answer
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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .