Mega was second: The first client-encrypted file sharing service, Securesha.re

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.

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.

Did you literally create an account just to say that?

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:

https://tahoe-lafs.org/trac/tahoe-lafs

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/)

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.

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.

-- 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)

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.

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.

https://github.com/STRML/securesha.re-client/commit/d5228650...