Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build your own private, encrypted, open-source Dropbox clone

gist.github.com

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Build your own private, encrypted, open-source Dropbox clone

#11

Post by Wilya »

luisehk wrote: post #2

I wonder if this is really usable like Dropbox. I tried owncloud which is supposed to be the more stable alternative but it kept replacing new files with old ones, sync took ages and security was weak. I really want to support this kind of projects but they hold me from being productive, which I really need right now.

Owncloud client is based on csync, which a quite weak system compared to unison, in terms of file consistency.

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.

Re: Build your own private, encrypted, open-source Dropbox clone

#12

Post by Tho85 »

sehrope wrote: post #10
brymaster wrote: post #8

This should be taken a step further and have a UI and web control panel just like the real dropbox.

Putting aside the work itself of creating a UI (this is just a simple install guide), that's not possible without exposing the encfs keys to the remote server. In this setup the client data is all encrypted before it reaches the server. The server is just a sync point for multiple clients. 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 c…

Theoretically, it should be possible to have a web UI running on the server itself. You just need a decent AES implementation in Javascript to do client-side decoding of filenames and files. Any volunteers? :-)

Edit: Looks like someone is already working on it: http://stackoverflow.com/questions/10909500/use-encfs-with-j...

Re: Build your own private, encrypted, open-source Dropbox clone

#13

Post by Tho85 »

aw3c2 wrote: post #9
Tho85 wrote: post #5

Earlier quoted context omitted.

The underlying sync software (Unison) has been around for years now and is regarded as stable. So syncing should work just fine, although you should keep a backup of your files just in case. 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…

I often have Unison not notice file changes until I repeatedly scan or sometimes even until weeks later. If I new a better alternative I would not use it.

They use some kind of heuristic to make change detection faster, see their documentation: http://www.cis.upenn.edu/~bcpierce/unison/download/releases/...

Maybe that's the root cause of your issues?

Re: Build your own private, encrypted, open-source Dropbox clone

#15

Post by duaneb »

bmslieght wrote: post #6
Tho85 wrote: post #4

Earlier quoted context omitted.

You don't have to if you use EncFS. All encryption is done client-side. 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).

Your VPS provider, can in effect, chroot in to your environment, so EncFS is vunerable.

If encryption is done client-side, the data is still encrypted server-side and chrooting does nothing.

Re: Build your own private, encrypted, open-source Dropbox clone

#16

Post by Tho85 »

bmslieght wrote: post #6
Tho85 wrote: post #4

Earlier quoted context omitted.

You don't have to if you use EncFS. All encryption is done client-side. 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).

Your VPS provider, can in effect, chroot in to your environment, so EncFS is vunerable.

What do you mean by 'vulnerable'? All encryption is done on your computer/notebook, so a chroot on the server doesn't decrypt the files.

Re: Build your own private, encrypted, open-source Dropbox clone

#18

Post by colinsidoti »

Tho85 wrote: post #12
sehrope wrote: post #10

Earlier quoted context omitted.

Putting aside the work itself of creating a UI (this is just a simple install guide), that's not possible without exposing the encfs keys to the remote server. In this setup the client data is all encrypted before it reaches the server. The server is just a sync point for multiple clients. 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 c…

Theoretically, it should be possible to have a web UI running on the server itself. You just need a decent AES implementation in Javascript to do client-side decoding of filenames and files. Any volunteers? :-) Edit: Looks like someone is already working on it: http://stackoverflow.com/questions/10909500/use-encfs-with-j...

I've looked into this before and concluded it was possible, although I forget exactly how.

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.

Re: Build your own private, encrypted, open-source Dropbox clone

#19

Post by sehrope »

colinsidoti wrote: post #18
Tho85 wrote: post #12

Earlier quoted context omitted.

Theoretically, it should be possible to have a web UI running on the server itself. You just need a decent AES implementation in Javascript to do client-side decoding of filenames and files. Any volunteers? :-) Edit: Looks like someone is already working on it: http://stackoverflow.com/questions/10909500/use-encfs-with-j...

I've looked into this before and concluded it was possible, although I forget exactly how. 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 op…

It's a really interesting idea (and sounds really fun to build) but a bad idea from a security perspective. Javascript crypto in the browser just doesn't make sense[1].

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/

Post reply on HN