Encrypted remote filesystem with concurrent access - is it possible?

1

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.

yardena

Posted 2011-07-26T04:26:38.547

Reputation: 291

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 – 2011-07-26T04:31:53.170

Answers

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.

Mike Rowave

Posted 2011-07-26T04:26:38.547

Reputation: 1 835

Only problem with that is that incremental diffs aren't going to be effective because of the Avalanche Effect.

– Andrew Moss – 2011-08-11T13:56:52.557

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 – 2011-08-11T15:35:48.003

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 – 2011-08-11T15:45:12.730

Asked: 2011-07-26T04:26:38.547

Viewed: 800 times

Active: 2011-08-11T13:56:29.983