1

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.

Improve this question
1
  • 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, 2011 at 4:31

1 Answer 1

Reset to default
0

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.

Improve this answer
3
  • Only problem with that is that incremental diffs aren't going to be effective because of the Avalanche Effect.
    – Andrew Moss
    Aug 11, 2011 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, 2011 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, 2011 at 15:45

You must log in to answer this question.

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