Set up your own truly secure, encrypted and shared file synchronization | Hacker News Reader

Set up your own truly secure, encrypted and shared file synchronization

raymii.org

69 pointsmdewinter23 comments

Two things:

1. You have been able to use rsync.net as a target for this scheme for ... 4-5 years now. [1]

2. https://news.ycombinator.com/item?id=5640700

  [1]

  ssh user@rsync.net "git init --bare autosync.git"
  Initialized empty Git repository in /user/autosync.git/

In fact ... we like this particular writeup so much that we are going to start pointing customers to it since it is a bit simpler than the EncFS/Truecrypt recipes we were handing out, and just works perfectly with the platform.

Thank you! Cheers!

If you drop an email to me with some more pointers I can edit the article with an rsync feature?

Are you still offering HN readers 50GB for $60/yr? That's insanely reasonable. I'd take you up on that.

This encrypts via encfs, so not sure what the advantage is over just using encfs on top of Dropbox (or any ol' provider)?

You keep the data fully under your control. Who knows whatever ram-scanning-key-searching tricks Dropbox or any other Closd Source piece of software utilize...

Does dropbox run as root?

You install the package/setup as root.

You don't have to, if you want to be that paranoid.

Why would dropbox even need that level of obfuscation for a backdoor? The binary just do evil directly (although having something that seems plausibly like a bug would be ideal.)

Big issue for me re: Dropbox clones, device integration/clients. iOS being key for me.

I've been using Sparkleshare (http://sparkleshare.org/) as a secure alternative to Dropbox, and it works decently, although it has some rough edges.

The Mac client crashes a lot with ~10 shared folders checked out in my experience.

Why does including the EncFS XML file make things much easier to crack?

The XML file contains encoded key and salt data. It also includes other metadata like KDF iterations, etc. Narrowing down the problem domain for the attacker leads to faster password cracking. While that is true using a strong password should render this attack useless.

Well how are you going to decrypt the files if you suffer data loss without that file? Plus, the key should be strong enough that this doesn't matter, yeah.

I like that dvcs-autosync is able to keep a history, but I wouldn't use it because it doesn't have the ability to delete old versions of a file yet.

Would something like git gc work when the repo is considerably big?

Git gets very slow with large files and isn't optimized for binaries. bup (https://github.com/bup/bup) is based on git but designed to solve this problem (has its own high-speed packwriter/readers).

Although still can't delete old data at the moment (though its being worked on).

Duplicity [1] is a good alternative too.

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

Duplicity is backup not sync.

In another thread, you mentioned bup. Quickly skimming bup's readme on github, I seem to only find references to the backup use case - not sync. Am I mistaken and bup also supports syncing, or did you bring up bup for another reason?

Someone mentioned using git - which has noted problems as a general purpose backup tool with large files. bup is the tool developed to solve those (git big-file is another, and technically git-annex could work that way but its not really a backup tool).

Reply on news.ycombinator.com