Build your own private, encrypted, open-source Dropbox clone
gist.github.com
gist.github.com
mkdir ~/Dropbox/_ ~/Dropsafe
encfs ~/Dropbox/_ ~/Dropsafe
But adding and removing files works as expected, so adding a few files to the encfs system, should translate to the same number of files added to the underlying folder.
[1] http://linux.die.net/man/1/encfs
[2] https://boxcryptor.desk.com/customer/portal/articles/565934
> Add a user for our project and give him a decent password:
Better off not giving the encbox user a password at all and only allow SSH key based login. You can already login to the primary/root account and sudo/su to setup the encbox user and copy SSH keys.
[1] http://www.slashgeek.net/2013/05/16/host-your-own-dropbox-li...
What is special about their VPS offering that makes it so cheap? I mean, from what I can see for an extra $2/month they let you host websites and install anything you want (except torrents, TOR or anything illegal).
I've been wanting to have an affordable VPS solution so I could be host my own stuff, and have the freedom to experiment with various development tools, and this might be a decent deal.
However as you can see from the SLA (99.9%), you do have to pay something in the form of reduced redundancy and availability. If, for example, an HP RAID card freaks out and all the VM's get corrupted on your blade, well you are out of luck. That data is gone forever. It's a small risk, but it is a real one (in fact with the P410 they are using, that's actually happened to me before in production). There are lots of other things that can go wrong too. Virtualization is not all rainbows and unicorns.
In the end I think it's still a good deal if you need a backup target with phat storage in it. But if you are interested in just trying out stuff, I think Digital Ocean is a better call since they have a higher SLA (99.99%) and probably a better dashboard and it's around the same price. Backupsy, as the name implies, is made for backups.
Note: Not affiliate in any way with RamNode, just an happy client.
https://clientarea.ramnode.com/cart.php?gid=11
And got the 256 RAM one, it has 90 GB space. Then I used the leb35 code the GP gave me, and it comes out to $29.83 yearly.
This will give you encrypted, snapshotted backups using open-source systems, that are better than Duplicity because you don't have to be creating full backups every so often. If you'd be interested, you can subscribe to my mailing list at http://bit.ly/stavroslist or follow me on Twitter or something, but please post comments below so I know what functionality to include.
What I am looking for is a folder that syncs, but is secure and open source.
BitTorrent Sync is the closest to how it should work, but is not open source: http://labs.bittorrent.com/experiments/sync.html
I retain off-site encrypted HDD images updated once a month of things like media which constitute the vast majority of my data and do not need daily snapshots.
http://doc.owncloud.org/server/5.0/admin_manual/configuratio...
$ ssh-copy-id encbox@your.vps.com
(Disclaimer: I’m interaction designer on ownCloud.) With ownCloud Inc. we have a company, customers and full-time employees. There’s no reason for it to not be able to compete except time needed to catch up to par.
And also the code happens to be open source. In that respect it’s a challenge because we don’t have the one centralized reference server where everyone has an account. There are people running it on Ubuntu, Debian, CentOS, Windows Server, …, Apache, Nginx, Lighttpd, …, with MySQL, SQLite, PostgreSQL, Oracle, …, not to mention the different browsers people use it with (we support down to IE8) and operating systems the clients use.
Anyway, I digress. ownCloud is also a synchronization service for desktop and mobile devices. In fact we don’t have any system-to-system syncing built-in.
The mobile clients and especially the desktop client have gained a lot in stability in the last few weeks – if you’ve tried before, I encourage you to give it another shot. We’re also in the process of reworking the design for the mobile apps. Overall simplification, better visual design. Let me know if you have any specific feedback.
Unfortunately it is not opensource, but is is still better than dropbox, because it does not store my files in cloud and it has better setting - i can choose which folders on my device i want to backup or synchronize.
>Will you backup my Backup VPS?
> Unfortunately, no. Even though we use a RAID protected setup, there is still a slight chance of data loss due to RAID controller failure. For extreme redundancy you can order 2 backup VPS in different nodes and we can mirror them for you ("Configure it for me" addon should be purchased).
The correct solution involves using FSEvents (which blows), and system poling when you get an event. Inotify is good enough to get away with no poling. The native windows change watcher isn't bad either.
Even if this weren't the case, the value that dropbox provides is far greater than this potential solution for most people- ie, there is quite a bit of room for something to go wrong running your own duct tape dropbox. Syncing 99/100 files is not OK. Syncing 100/100 files, but only after 2 weeks isn't OK either.
source: I built my own ducktape dropbox (sortof). https://github.com/Floobits/flegmatic
You can also use Dropbox and Encbox together if you're unsure: Point your Dropbox installation to ~/Encbox and have Dropbox sync your (then decrypted) files. So you can be sure to have backups, file sharing features, etc. and see if Encbox is stable enough for you.
Maybe that's the root cause of your issues?
No idea how well unison performs in constant Dropbox-like usage, but you shouldn't let the flaws of Owncloud deter you: file synchronisation isn't Owncloud's strong point.
You could have a UI (web or otherwise) on a separate client but it would have nothing to do with the server. It would just be a client that provides a UI interface to the decrypted encfs filesystem.
Edit: Looks like someone is already working on it: http://stackoverflow.com/questions/10909500/use-encfs-with-j...
I bookmarked https://crypton.io/ and http://peerjs.com/ . PeerJS is p2p WebRTC, which I believe I chose because I wanted to do secure, real-time p2p file sharing.
That isn't 100% relevant for this, but downloading the file over some socket into client-memory then decoding it there sounds like something webrtc could be a good option for.
Crypton handles the crypto.
I think the biggest thing someone who tackles this needs to realize is that perfecting the crypto doesn't matter 100%. If you could get something working that's doing some kind of encryption/decryption without exposing anything to the server, crypto experts will come in and help secure everything (see: mega)
Edit: I should mention that I didn't research this extensively, and better libraries might be (and probably are) available.
Summary of the link: Since you trust the server to serve the JS files, you might as well trust it to do the decryption and present it all over SSL.
> I think the biggest thing someone who tackles this needs to realize is that perfecting the crypto doesn't matter 100%. If you could get something working that's doing some kind of encryption/decryption without exposing anything to the server, crypto experts will come in and help secure everything (see: mega)
This is an especially bad idea. Application that perform crypto should be designed properly from the start. It's not something you can just patch on later. Building crypto programs to learn/test/explore is fine but building a product for actual usage and then expecting others to fix it after the fact is a terrible approach.
[1]: http://www.matasano.com/articles/javascript-cryptography/
The main issue here is that your Javascript can potentially be owned by XSS or other approaches. If you own the javascript, you can send plaintext passwords or keys (which should have only been available to the client) back up to some server.
Even with that possibility though, I still think using browser-based crypto creates a more secure environment than the server storing unencrypted files. The author makes a good point in saying that you download javascript on each request, which makes it more susceptible to getting owned than a native-app, but I think a successful attack with this approach will still be an order of magnitude less severe than if an attacker owned a server full of unencrypted data. If the data is unencrypted, an attacker that manages to own the server has access to everyone's data. With it encrypted, the attacker will only get data from users who are using the site while it's owned.
Isn't that still a better option?
On the contrary go right ahead. Learning through doing is the way to go. I'm just saying there's a big difference between testing/learning/prototyping and releasing something that is claimed to be secure. Otherwise you end up with Cryptocat[1].
> Even with that possibility though, I still think using browser-based crypto creates a more secure environment than the server storing unencrypted files.
If you're using any JS then you have to completely trust the server that is serving it. At any point the server could replace "good.js" with "bad.js" and the browser will happily execute it. Any encryption you perform on the client side would be moot as "bad.js" could do whatever it wants with your plaintext and your encryption keys.
> If the data is unencrypted, an attacker that manages to own the server has access to everyone's data. With it encrypted, the attacker will only get data from users who are using the site while it's owned.
Again you're trusting the server to not save your encryption keys though by serving you "good.js" and not "bad.js"! All roads lead back to you trusting the server to play nice.
Unless you use untrusted remote services as opaque object stores and handle all encryption via secure code on the client side with proper signatures to prevent remote tampering[2], you're trusting the server not to compromise you.
[1]: http://en.wikipedia.org/wiki/Cryptocat#Security_concerns
[2]: Tarsnap (https://www.tarsnap.com/) is a perfect example of a client not trusting the server. The tarsnap service stores it's data on S3 but first all data is encrypted client side on your own machine. From the tarsnap service's perspective it's just storing a bunch of random binary blobs and that's all your client sends/recieves. Encryption/decryption happens locally on your machine.
So there are two problems:
1) You get code from the server and execute it -- it might not be the code you think it -- it might not be the code you got yesterday (and there might be third party code injected, if there is an XSS vector -- or you know, your browser doesn't check to see if the servers ssl certificate has been revoked...).
2) Even if you run the code locally (say distribute it as html+js+css "app" in a zip file signed with gpg) -- it is still running on top of a pretty rickity rack of technologies, your javascript vm, the browser dom, a mess of ui toolkits and c/c++ routines that manage memory -- and has been seen again, and again -- it is really hard to actually implement crypto in such a way that there are no side channel attacks, no timing attacks and no information leaks.
Essentially 1) running random code isn't secure, and 2) implementing good crypto is hard. Really hard.
The only real solution is to get a good crypto-api into html5/browsers, but even then things aren't "safe". Say you could:
plaintext = api.crypto.decrypt(AES-256-CBC, \
ciphertext, key)
Reference Link: http://docs.oracle.com/cd/E19253-01/819-5461/gbinw/index.htm...
The only thing your VPS provider could do is delete your files, but Unison's backup feature should protect you from losing your files (in a way).
I can still follow this guide to create my online-NAS box and use it across devices.