Announcing the first client-encrypted in-browser file sharing service, Securesha.re

End-to-end encryption in a file sharing service

There has been a lot of buzz the last few days about Mega, Kim Dotcom's newest product, the successor to MegaUpload. Many are claiming that client side JavaScript crypto has never before been used for this. But more than two months ago, I and a small team built the first end-to-end encrypted file sharing service, Securesha.re.

Securesha.re is a file sharing service much like MegaUpload or RapidShare, with an important twist; all files are encrypted in your browser. Browser support is wider than Mega: we support Chrome, Firefox, Safari, and Chrome for Android. We are not able to see your file's contents or name, and we have no means to access them. We do not log IPs and have no means to know what is being shared on our service.

Additionally, Securesha.re allows for automatic self-destruction of your files; by default, your files will self-destruct after 10 views or 7 days.

Securesha.re is not Mega - it is not meant for long-term file storage. Securesha.re is meant for end-to-end transmission and transient storage only. It is not currently possible to keep files on Securesha.re for longer than 7 days; this is a feature, not a bug.

We have been up since AngelHack DC, November 18th 2012.

We believe that the smaller an application is, the greater the chances of it being truly secure. To help with that, the client-side code is small and simple enough to understand and is intentionally kept public for review.

Why does this exist?

File sharing on the web is fraught with problems from the very beginning.

By sharing your files, anywhere, on almost every mainstream service, you implicitly trust the operators not to look at your files. This introduces a number of problems if you don't want your data to be available to just anyone:

1. You must be very careful to store your file on a service that randomizes its URLs, so it cannot be found simply by chance.
2. You must store your files in an encrypted archive. To do this, you must have an archiver capable of encryption, and the knowledge to choose a secure algorithm.
3. You should be careful to delete your files after the intended recipient(s) have downloaded them.

It is unlikely that the average computer user will have the knowledge to follow all three of these steps. Yet everyone has files that should they want to privately share. Many encounter this on a regular basis with family, business partners, lawyers, landlords, and so on.

Email is a decent alternative but you must be very careful to encrypt properly as email is often transferred in plain-text. In addition, your archive may live nearly forever (e.g. Gmail) in the recipient's mailbox. If the data is truly sensitive this may not be acceptable.

Securesha.re solves these problems in a way that is so simple, your grandmother can use it.

How to Use Securesha.re

It is simple to use the service: simply attach a file and click upload.

We have only a minimal set of options. You may specify a date and number of views allowed on your file. The file will be deleted after receiving that number of views, or once the date has been reached.

For now, defaults and maximums are 10 views and 1 week.  File size maximum is 10MB. We may introduce a paid option that allows for more customization.

Securesha.re can easily be used as a simple encrypted end-to-end transfer service. Simply set your view limit to 1 and the file will be deleted as soon as the recipient has downloaded it.

Public Repo

For those of you who are security fanatics, all client-side code is purposely kept un-minified for inspection. You can see exactly how your data is sent. The simplest way to verify I am not being sent any compromising information is to look at your inspector's Network tab.

The client-side files are hosted in a public repo on GitHub. Pull requests are very welcome.

Technical Details

Uploaded files are grabbed as binary strings using the HTML5 File API. They are then encrypted using CryptoJS's fast AES encryption algorithm. Files are encrypted and decrypted in 512kb chunks by up to 4 web workers for extra speed. Encryption/decryption reaches about 2MB/sec on an i5 Macbook Air.

Files are sent to our server which stores on S3. File contents and name are encrypted separately. MIME type is sent in the clear for analytics; these are the only analytics we have. We do not log IP addresses.

We are very careful not to include any plugins or outside JavaScript inside Securesha.re. That means no analytics, no Facebook connect, no Flash copy-paste, nothing. All assets are loaded from our server.

When downloading, the file is decrypted in chunks, reassembled, and transformed into a Blob object. Unfortunately, Safari doesn't support Blob URLs - the application will fallback to data-URIs, but this tends to crash the browser after ~6MB. Securesha.re will notify you of this if it applies.

Securesha.re does not exist to make money and is likely to remain as a proof-of-concept rather than a full-blown sharing service.

Who are you guys?

This project came out of AngelHack DC, a 24-hour hackathon hosted on November 17-18th. I am Samuel Reed; my partners are Kevin Ohashi and Sean Perkins.

Updates

Since posting this article, we have moved securesha.re to HTTPS, from Rabbit encryption to AES encryption, and we've increased the default random password size from 16 chars (62^16 possibilities, roughly 2^96) to 24 chars (62^24 possibilities, about 2^143).