

Mega was second: The first client-encrypted file sharing service, Securesha.re - STRML
http://blog.strml.net/2013/01/mega-was-second-announcing-first-client.html

======
jonemo
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.

~~~
rarrrrrr
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.

------
ghubbard
_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._

~~~
STRML
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.

~~~
exec
Not 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
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.

A good read on the matter is Matasano's JavaScript Cryptography Considered
Harmful: <http://www.matasano.com/articles/javascript-cryptography/>

~~~
STRML
I wasn't aware of the MITM issues, thank you for letting me know. I'm working
on setting up a cert as we speak.

------
singleuse
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.

~~~
bascule
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>

------
chmars
What's about Wuala (<http://wuala.com/>)? It has been available for years and
is owned by Lacie today …

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

~~~
Angostura
> 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>

~~~
STRML
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.

------
doppel
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.

------
mahesh_rm
I'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
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.

~~~
STRML
In 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.4 _10^38 keys.

The fastest supercomputers in the world would take about 1.02_10^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...](http://www.eetimes.com/design/embedded-internet-
design/4372428/How-secure-is-AES-against-brute-force-attacks-)

~~~
mentat
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.

------
RachelF
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?

------
kybernetikos
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.

------
benologist
This 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.

------
nwh
> The default is secure and randomly generated;
    
    
        var passphrase = Math.uuid(16);
    

We're done here.

~~~
STRML
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...](https://github.com/STRML/securesha.re-
client/commit/d5228650226e38f234a352fde7ff54a2cfa1f400)

~~~
nwh
None of the random() functions in most JavaScript engines are
cryptographically secure. There's proposed RNG that are, but only in Webkit.

~~~
STRML
That's a good point. I will switch the random number generation to SJCL, which
uses mouse movement to seed the generator & hashes the aggregate.

