7 ms·
Mega was second: The first client-encrypted file sharing service, Securesha.re
- chmars 14y agoWhat's about Wuala (http://wuala.com/ http://wuala.com/)? It has been available for years and is owned by Lacie today …
- STRML 14y agoWuala is a desktop app - this is a website that works everywhere on most modern browsers, including Chrome for Android. Securesha.re wouldn't have even been possible a year ago; it relies on some very new File API calls that were recently added by the W3C. (http://www.w3.org/TR/FileAPI/ http://www.w3.org/TR/FileAPI/)
- saurik 14y agoOver a year ago, it was a safe bet that users had Flash installed (more than today are likely to have a "modern browser"). Flash can read files directly with, AFAIK, arbitrary complexity and was specifically popular to build improved file upload widgets (such as Facebook's photo importer tool). This concept thereby doesn't really "rely" on the File API (so one could easily imagine there having been someone doing exactly this many years ago, not that "first" is really relevant anyway ;P). In the case of Wuala, they actually were totally available via web browsers [1]; they used Java, however, instead of Flash, as seemingly their desktop client was already written in Java, so this was convenient. (Additionally, Java came pre-installed on most systems, albeit Windows shipped with the ancient 1.1 version, of course, due to that lawsuit.) You can find presentations from 2009 discussing the technical issues that went into this [2]. [1]: http://www.wuala.com/en/launch/ http://www.wuala.com/en/launch/ [2]: http://jazoon.com/portals/0/Content/ArchivWebsite/jazoon.com/jazoon09/download/presentations/10100.pdf http://jazoon.com/portals/0/Content/ArchivWebsite/jazoon.com... This method did, of course, involve getting pulled out of the web browser, but AFAIK that was not a technical requirement of Java for this purpose. (They claim in the presentation that a "Web App", even with Flash, wasn't capable of client-side encryption, which doesn't make much sense to me; maybe they just didn't want to implement the encryption algorithm? I also do not see them considering embedding the Applet into the website as opposed to just using it to launch their external app, but again: convenience to their existing codebase is likely a strong factor.)
- Angostura 14y ago> this is a website that works everywhere on most modern browsers, including Chrome Well, actually - it only seems to work fully on Chrome. https://mega.co.nz/#blog_1 https://mega.co.nz/#blog_1
- STRML 14y agoI'm speaking about my site, not Mega, which works in Firefox, Chrome for Android and Safari. Although Safari support is limited for now and has actually moved measurably backwards in the last few weeks. The better version of this post likely would have been a "state of browser-based encryption"; we're so close to really being there but any possible implementation is still a slow hack that won't work on all systems.
- doppel 14y agoI actually think Mega was third, and Securesha.re second, as Blindvault.com has been up for around half a year. It's not free though, but it compares in that files are encrypted user-side and if you don't have the key you can't tell if there are files, what the content is, etc.
- benologist 14y agoThis really depends on whether Mega turns out to be a file sharing service or piracy-as-a-service. Passworded zips predate them all I think.
- mahesh_rm 14y agoI'm not security expert, but isn't this: "128-bit client-side Rabbit encryption" obsolete practice? Doesn't mega use 2048? This is kind of big deal. And, of course, mega interface is a lot more than a simple "cryptolink" service. I actually feel that if mega will come up with good APIs (as well as with a client for dummies), and nobody will raid Kim for a second time, dropbox and alikes are gonna have bad times.
- chmars 14y agoAren't you comparing apples and oranges? More bits don't equal better encryption … In the case of Mega, the claim of 'military-grade encryption' sounds too much of snake oil as I would want to try the service. Kim Schmitz' past isn't a reason to trust him either.
- STRML 14y agoIn addition, 128-bit encryption is more than safe. In order to brute force it (and you will have to, there are no known vulnerabilities in Rabbit), you need to try up to 3.410^38 keys. The fastest supercomputers in the world would take about 1.0210^18 years to crack 128-bit encryption. See more on this topic (article is about AES, but the basics apply): http://www.eetimes.com/design/embedded-internet-design/4372428/How-secure-is-AES-against-brute-force-attacks- http://www.eetimes.com/design/embedded-internet-design/43724...
- mentat 14y agoThe basics of a well reviewed cipher do not apply to a random experimental cypher you've chosen instead. Why would you not use AES? It's the best understood cipher in the world right now. "more than safe" just doesn't make sense. Please read all of parent's posts in this thread and do not use their product.
- nwh 14y agoJust because they can't be cracked publicly, doesn't mean that there isn't a way to do it. There could be any number of weaknesses in any algorithm that mean that the computation time can be drastically reduced. WEP is a prime example, which you should probably be familiar with.
- ghubbard 14y agoIt is not currently possible to keep files on Securesha.re for longer than 7 days; this is a feature, not a bug. We do not use HTTPS at the moment. As all file transmissions are encrypted, we did not consider it necessary at the moment. A snooper could see the URL of files you have uploaded; however, the password will not be seen.
- STRML 14y agoHTTPS is not always the answer, and Securesha.re is not meant to be a direct competitor to Mega. We are focused less on enabling the sharing of movies & applications and more on the sharing of sensitive documents, private information, and so on.
- exec 14y agoNot using HTTPS is a critical mistake. Adversary can just do MITM attack and send modified code to the user's browser to steal passwords. It's not best idea to share sensitive documents without using HTTPS.
- bascule 14y agoConfirm. This system was obviously designed by people who had no idea what they were doing, which is about the last thing you want in a cryptosystem. Failing to authenticate the JS cryptographic code (TLS would've helped here) makes this system effectively worthless and simple to MitM. A good read on the matter is Matasano's JavaScript Cryptography Considered Harmful: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
- jonemo 14y agoMega could be the twentieth to do this and do it badly, with the amount of media attention Kim Dotcom is getting they would still have 50% of the market share half an hour after launch.
- rarrrrrr 14y agoIndeed. For those of us who have been in this industry for years, the whole situation feels Condescending Wonka-esque. "Oh, you're creating a zero-knowledge cloud service? Tell us all about how revolutionary it is." (I cofounded SpiderOak in 2007.) I'm glad it's happening though. The industry needs more awareness of privacy and more choices for privacy respecting products. This will undoubtedly grow the market for cloud services with meaningful encryption.
- bascule 14y agoDoesn't really matter if you're "first" with a cryptosystem if it's horribly, horribly insecure either. Putting out badly designed cryptographic software like this is just irresponsible.
- singleuse 14y agoWhat a shameful attempt at surfing the dotcom marketing campaign. Virtually nobody cares who was first, what matters is respect of privacy and secure encryption.
- STRML 14y agoDid you literally create an account just to say that?
- bascule 14y agoI think the worst part is they're claiming they're the "first" when really they're not (not even for browser-based systems). There have been many encrypted cloud storage systems which worked according to this philosophy. Allmydata.com (now defunct) and Tahoe-LAFS come to mind: https://tahoe-lafs.org/trac/tahoe-lafs https://tahoe-lafs.org/trac/tahoe-lafs
- kybernetikos 14y agoNo love for JungleDisk, which was one of the first cloud backup systems I ever heard of? I suppose it wasn't really for sharing, but still, the fact that neither amazon nor his server had the keys is one of the things that made me interested in it.
- RachelF 14y agoThere quite a few apps out there that encrypt cloud storage end-to-end. I use Syncdocs (http://syncdocs.com http://syncdocs.com) to encrypt Google drive storage. Kim Dotcom is giving away a lot more free space, than Dropbox. But he has a bit of a reputation problem, and no one has independently checked his algorithm yet?
- nwh 14y ago> The default is secure and randomly generated; var passphrase = Math.uuid(16); We're done here.
- STRML 14y agoEssentially, that's a call to Math.random() 16 times that picks from a pool of 62 characters each time, allowing for 62^16 possible combinations, or 4.7 * 10^28 possibilities. You've made me aware that this could possibly make brute forcing easier, as it is nearly equivalent to a 96-bit key length. While even a brute-forcing 96-bit key would theoretically take about 230 million years on today's top-of-the-line hardware and therefore is not (currently) insecure, it does not make sense to introduce that weak point. Therefore, I've updated the current random passwords to be 24 characters in length from now on, which pushes it far above 2^128. https://github.com/STRML/securesha.re-client/commit/d5228650226e38f234a352fde7ff54a2cfa1f400 https://github.com/STRML/securesha.re-client/commit/d5228650...
- nwh 14y agoNone of the random() functions in most JavaScript engines are cryptographically secure. There's proposed RNG that are, but only in Webkit.
- STRML 14y agoThat's a good point. I will switch the random number generation to SJCL, which uses mouse movement to seed the generator & hashes the aggregate.