HN Explorer

Dropbox clone with git, ssh, EncFS and rsync.net

54 points by rsync ↗ HN
We've been trying to solve this problem for longer than Dropbox has existed: how can you maintain plaintext locally and ciphertext remotely, easily, with efficient changes-only (a la rsync) sync ?

We created a lot of half-working Truecrypt/Filevault/encfs schemes and fiddled with a lot of --partial --progress --whatever switches to rsync, but eventually we just told people to use duplicity[1][2] and call it a day.

Then Mr. Raymii came along and dropped this in our lap:

https://raymii.org/s/articles/Set_up_your_own_truly_secure_encrypted_shared_storage_aka_Dropbox_clone.html

The tl;dr there is:

"This article describes my truly secure, encrypted file synchronization service. It used EncFS and dvcs-autosync which lets me share only the encrypted data and mount that locally to get the plaintext."

... and we couldn't be happier. Finally we (and anyone using rsync.net, or any ssh host with git on it) have an elegant way to sidestep the issues of trust and authority[3] over remote data on systems you don't control.

Enjoy! [4]

[1] http://duplicity.nongnu.org/

[2] ... and it's still a very good solution.

[3] http://www.rsync.net/resources/notices/canary.txt

[4] HN discount is 10c/GB/mo. Just email us.

29 comments

[ 3.0 ms ] story [ 82.6 ms ] thread
JimmaDaRustla
YES!! This is exactly what I've been looking to do!! Going to replicate this to RamNode host where I get 50GB for $1.38/month.
lcedp
I see price there starting from $24/year.
JimmaDaRustla
Sorry, forgot to mention the coupon code from serverbear.com: SB31

31% off for life - 24*0.69/12=1.38

Enjoy!

Edit: Not to mention the other uses I get out of my VPS - voice chat server, VPN tunneling for my Roku (In Canada), game server, etc. Ofcourse, if you are storing important information, I wouldn't suggest loading up your VPS with services increasing risk of hacking.

cypherpunks01
Could Tahoe-LAFS be used for this purpose?
rsync
A few comments about that...

To be a Tahoe-LAFS "target" you do need to be running their code on the server side ... and it's python.

We make a point to keep our environment as simple and sanitized as possible, which implies having no interpretors, so at this time you can't use rsync.net as a Tahoe-LAFS target.

BUT! We've always been very excited about Tahoe-LAFS and are well acquainted with Zooko and his team, etc., and so we are experimenting with a frozen[1] implementation of it that we can place into our environment as a binary executable[2].

The two solutions aren't really that related, as Tahoe-LAFS (sort of) implies that rsync.net would be just one of many (perhaps ten) remote containers out there, whereas this solution is targeted to just one remote host... but since you asked ...

[1] http://cx-freeze.sourceforge.net/

[2] We already do this with rdiff-backup, which is how we are able to support that ...

cdjk
That's exciting, and something I might be interested in. My question and concern, however, is that Tahoe-LAFS seems better suited for distributed storage among unreliable nodes. I consider rsync.net to be fairly durable storage, especially since the way I use it is as backup and not the only storage location for a file. I have the same question about using S3 as a tahoe backend, which is another thing I've seen.

Of course, you could just use Tahoe-lafs to store everything on one or two nodes when they're reliable and durable, but then why not just use gpg or encfs, which don't require custom clients or gateway/introducer nodes?

akama
I believe so. If I understand Tahoe-LAFS, it can be used in a system where you don't trust the host of the data. The other benefit of using it is that it has data duplication incase one server fails.
cdjk
I'm not sure how easy it would be to store git repos on Tahoe-LAFS, but there are two other options - 1) duplicity has native support for Tahoe-LAFS as a backend, or 2) use git-annex with a special remote [1].

[1] http://git-annex.branchable.com/special_remotes/

nuclear_eclipse
Does this make any attempt to handle conflicts on files when changed on two offline hosts? I assume since it's based on Git it will just try to do merges that way, but how does it handle conflicts that can't be automatically resolved?
chubot
How much does encryption defeat the rsync algorithm? I don't see anything in the article that addresses that.

That is, say you change one line in 1 MB text file. If you rsync plain text, it will transfer a handful of bytes. If you encrypt and then rsync encrypted text, then presumably a lot more bytes will be scrambled and you will have a bigger diff to transfer. I guess it depends on the block size.

rsync
It depends.

If the resulting file is truly random vs. the last time you mounted it, then you (of course) need to retransmit everything.

However, imagine that every time you closed your TC volume or unmounted filevault it had to rewrite an entirely new multi-GB file ? Of course that would take forever and would be difficult to use.

So most encryption image software organizes the image internally such that new data written only affects portions of the file. And then, in theory, rsync with options like --partial --inplace --whatever will then transfer it efficiently.

BUT, our experience is this seldom works properly. The amount of internally changed data changes dramatically form usage to usage, and often has very little to do with the amount of actual data you changed. We just never got it to work well, consistently.

nsomaru
Does this mean you guys found that a large portion of the encrypted file had to be retransmitted as compared with the number of bits actually changed?

How does one consistently store encrypted data using rsync.net as a backend, whilst maintaining the benefits of the rsync protocol?

This seems to rule out the benefits of using rsync w/ encrypted files.

Is there something I'm missing?

lcedp
The thing is to stay secure you need to re-encrypt the whole file. Otherwise you will get this: https://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio... That's why encfs uses the second mode in the list (chaining).
nsomaru
Could you expand a bit? I've been thinking of building a bandwidth efficient encrypted syncing system, and this article (almost) hits the spot.

How is the best way to get this done, security considerations as against bandwidth?

lcedp
I'm not highly knowledgeable in security, but the gist is if a block cipher uses the simplest mode of operation (ECB) each block is encrypted independently - good for sync bandwidth but from that the attacker can derive the structure of the file which will help to recover it or it can be used to check if known file in present in encrypted data(watermark attack [1]). More advanced block cipher modes "blend" to some extent blocks hiding file structure information (but if you change single bit a bunch (or all) of the blocks is changed). Also there are stream ciphers, which don't use blocks at all. If you change 1 bit stream cipher will change 1 bit in its output. The problem is it's insecure to use the same key twice with stream cyphers (reused key attack - [2])- e.g. if files with known text is encrypted (think English text, xml files, jpeg headers). Of course it can be overcome by using initialization vector ("seed" which is used with the key), but that IV should be different for each file and you should somehow save it to be able to decrypt it.

[1] https://en.wikipedia.org/wiki/Watermarking_attack [2] https://en.wikipedia.org/wiki/Stream_cipher_attack

chubot
Try doing the matasano challenges :). I completed the first two and it was my first exposure to block cipher weaknesses. I had almost zero crypto knowledge before that. All you need to know is programming and basic arithmetic.
[deleted]
(comment deleted)
kzrdude
Ideally git-annex should be able to cover this in the future.
prirun
You can do this with HashBackup too (I'm the author). There are sites using HB to backup terabytes of data. One of the larger sites has 25M files they backup every day.

  1. Copy ssh public key to rsync.net server:

  [jim@mb hbdev]$ scp ~/.ssh/id_rsa.pub XXXX@usw-s002.rsync.net:.ssh/authorized_keys
  Password:
  id_rsa.pub
			 100%  392     0.4KB/s   00:00    


  2. Create a local HashBackup backup directory:

  [jim@mb hbdev]$ hb init -c hb
  HashBackup build 1070 Copyright 2009-2013 HashBackup, LLC
  Backup directory: /Users/jim/hbdev/hb
  Permissions set for owner access only
  Created key file /Users/jim/hbdev/hb/key.conf
  Key file set to read-only
  Setting include/exclude defaults: /Users/jim/hbdev/hb/inex.conf

  VERY IMPORTANT: your backup is encrypted and can only be accessed with
  the encryption key, stored in the file:
      /Users/jim/hbdev/hb/key.conf
  You MUST make copies of this file and store them in a secure location,
  separate from your computer and backup data.  If your hard drive fails, 
  you will need this key to restore your files.  If you setup any
  remote destinations in dest.conf, that file should be copied too.

  Backup directory initialized


  3. Create a dest.conf file in the backup directory:

  [jim@mb hbdev]$ cat - >hb/dest.conf
  destname rsyncnet
  type rsync
  dir NNNN@usw-s002.rsync.net:
  password XYZZY


  4. Enable dedup using up to 1GB of memory:

  [jim@mb hbdev]$ hb config -c hb dedup-mem 1g
  HashBackup build 1070 Copyright 2009-2013 HashBackup, LLC
  Backup directory: /Users/jim/hbdev/hb
  Current config version: 0
  Showing current config

  Set dedup-mem to 1g (was 0)


  5. Create a test file, 10 x 10k random blocks

  [jim@mb hbdev]$ dd if=/dev/urandom of=ran10k bs=10k count=1
  1+0 records in
  1+0 records out
  10240 bytes transferred in 0.001602 secs (6392272 bytes/sec)

  [jim@mb hbdev]$ cat ran10k ran10k ran10k ran10k ran10k ran10k ran10k ran10k ran10k ran10k >test100k

  [jim@mb hbdev]$ ls -l test100k
  -rw-r--r--  1 jim  staff  102400 Oct 15 14:20 test100k


  6. Backup the test file:

  [jim@mb hbdev]$ hb backup -c hb test100k
  HashBackup build 1070 Copyright 2009-2013 HashBackup, LLC
  Backup directory: /Users/jim/hbdev/hb
  Using destinations in dest.conf
  This is backup version: 0
  Dedup enabled, 0% of current, 0% of max
  /Users/jim/hbdev/test100k
  Writing archive 0.0
  Copied arc.0.0 to rsyncnet (11 KB 2s 5.0 KB/s)
  Copied hb.db.0 to rsyncnet (4.3 KB 2s 2.1 KB/s)
  Copied dest.db to rsyncnet (340 B 2s 162 B/s)

  Time: 4.8s
  Wait: 6.5s
  Checked: 5 paths, 125418 bytes, 125 KB
  Saved: 5 paths, 125418 bytes, 125 KB
  Excluded: 0
  Dupbytes: 0
  Compression: 87%, 8.1:1
  Space: 15 KB, 15 KB total
  No errors


  7. Create a different test file, with junk at the beginning, middle, and end:

  [jim@mb hbdev]$ echo abc>junk

  [jim@mb hbdev]$ cat junk test100k junk test100k junk >test200k
  [jim@mb hbdev]$ ls -l test200k
  -rw-r--r--  1 jim  staff  204812 Oct 15 14:24 test200k


  8. Backup the new file:

  [jim@mb hbdev]$ hb backup -c hb test200k
  HashBackup build 1070 Copyright 2009-2013 HashBackup, LLC
  Backup directory: /Users/jim/hbdev/hb
  Using destinations in dest.conf
  This is backup version: 1
  Dedup enabled, 0% of current, 0% of max
  /Users/jim/hbdev/test200k
  Writing archive 1.0
  Copied arc.1.0 to rsyncnet (42 KB 2s 15 KB/s)
  Copied hb.db.1 to rsyncnet (4.6 KB 1s 2.3 KB/s)
  Copied dest.db to rsyncnet (388 B 1s 207 B/s)

  Time: 3.0s
  Wait: 6.7s
  Checked: 5 paths, 227898 bytes, 227 KB
  Saved: 5 paths, 227898 bytes, 227 KB
  Excluded: 0
  Dupbytes: 122880, 122 KB, 53%
  Compression: 79%, 4.8:1
  Space: 47 KB, 62 KB total
  No errors


  9. What do the stats look like?

  [jim@mb hbdev]$ hb stats -c hb
  HashBackup build 1070 Copyr...
edwintorok
If someone is looking for an alternative to a closed-source product, I don't see why another closed-source product would be the answer (according to Hashbackup's FAQ it won't be open-source). Usually the goal of replacing a closed-source product is to have something that you can fully control / tweak / audit ...
mdewinter
@prirun is Hashbackup open source? Or close source and filled with backdoors?
jlund
git-annex is explicitly designed to avoid putting file contents under version control because git doesn't handle large files (like videos) very well. It seems like this system is running headlong into that problem. I'm probably going to be sticking with duplicity for now.
tmikaeld
Umm... Git-annex does this without it taking half an hour to do, plus it takes less very little effort to setup on multiple locations.
lcedp
> IMPORTANT! Make sure to remove the .encfs files from the secure folder before syncing. IF THESE FILES ARE IN THE SYNCED FOLDER, YOUR FILES ARE MUCH MORE EASIER TO BE CRACKED.*

What?! No don't do it! If you lost your .encfs6.xml file pretty much you lost everything. You can't decode your files back. Of course you don't have to sync it, you can back it up by other means. But you can't just remove it.