Wuala 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/)
Over 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].
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.)
I'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.
I 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.
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.
Aren'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.
The 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.
Just 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.
Rabbit is a symmetric cypher, and Mega's mention of 2048 is in respect to RSA, an asymmetric cypher. Even if Mega were using RSA to encrypt the entire file (as opposed to an encryption key which is then used to encrypt the file, which I personally find more likely, given the performance constraints and various other limitations of RSA, but maybe they really are doing that: I'm not an expert ;P), 2048-bit RSA is said by RSA themselves to be equivalent to a symmetric cypher with a 112-bit key.
> As of 2003 RSA Security claims that 1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys and 3072-bit RSA keys to 128-bit symmetric keys.
(Although, this is almost certainly ignoring mathematical attacks, as those would make things highly variable: one could imagine a really lame cypher that doesn't effectively utilize the key, or which leaks the key into the cyphertext. The choice "Rabbit" is thereby important, and Wikipedia mentions that if you want to break a large number of keys, such as for a large number of related files/accounts on a file-storage service, and just need to break any one, a 128-bit key is only about as effective as a 96-bit one.)
> Rabbit claims 128-bit security against attackers whose target is one specific key. If, however, the attacker targets a large number of keys at once and does not really care which one he breaks, then the small IV size results in a reduced security level of 96 bit. This is due to generic TMD trade-off attacks.
As a rule, asymmetric encryption requires more bits than symmetric encryption - RSA-1024 and AES-128 are both standard. I'm not sure what Mega is using asymmetric encryption for, but it doesn't seem to be necessary for this use case; that said, Rabbit is not a commonly used algorithm.
It 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.
HTTPS 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.
Confirm. 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.
You really misunderstand the role of HTTPS in the composition of a secure web page, namely securing the components from MITM against any of the active components which could result in a compromise of the entire page rendering. I have zero faith in the security of your solution if you don't or can't understand this.
Mega 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.
Indeed. 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.
Doesn'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.
What a shameful attempt at surfing the dotcom marketing campaign.
Virtually nobody cares who was first, what matters is respect of privacy and secure encryption.
I 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:
No 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.
There quite a few apps out there that encrypt cloud storage end-to-end. I use Syncdocs (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?
Essentially, 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.
33 comments
[ 45.0 ms ] story [ 420 ms ] threadIn 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/
[2]: 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.)
Well, actually - it only seems to work fully on Chrome.
https://mega.co.nz/#blog_1
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.
Passworded zips predate them all I think.
"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.
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.
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/43724...
> As of 2003 RSA Security claims that 1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys and 3072-bit RSA keys to 128-bit symmetric keys.
-- http://en.wikipedia.org/wiki/Key_size
(Although, this is almost certainly ignoring mathematical attacks, as those would make things highly variable: one could imagine a really lame cypher that doesn't effectively utilize the key, or which leaks the key into the cyphertext. The choice "Rabbit" is thereby important, and Wikipedia mentions that if you want to break a large number of keys, such as for a large number of related files/accounts on a file-storage service, and just need to break any one, a 128-bit key is only about as effective as a 96-bit one.)
> Rabbit claims 128-bit security against attackers whose target is one specific key. If, however, the attacker targets a large number of keys at once and does not really care which one he breaks, then the small IV size results in a reduced security level of 96 bit. This is due to generic TMD trade-off attacks.
-- http://en.wikipedia.org/wiki/Rabbit_(cipher)
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.
It's not best idea to share sensitive documents without using HTTPS.
A good read on the matter is Matasano's JavaScript Cryptography Considered Harmful: http://www.matasano.com/articles/javascript-cryptography/
Just curious, do you see any other red flags in the system?
"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.
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
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.
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?
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/d5228650...