
Crypto Analysis and Recommendations for Mega - rarrrrrr
https://spideroak.com/blog/20130123130638-spideroaks-analysis-and-recommendations-for-the-crypto-in-kim-dotcoms-mega-part-onehttps://spideroak.com/blog/20130123130638-spideroaks-analysis-and-recommendations-for-the-crypto-in-kim-dotcoms-mega-part-one
======
rarrrrrr
One of the points not mentioned in the article is that this analysis is useful
even if (like me, tptacek, and many others) you don't trust Javascript crypto.

That's because Mega is designed as simply an API that any client (including
one distributed as a desktop application) could implement. However, another
client implementing this same spec would have the same weaknesses. It's
important that we get the design improved now. Then we can go on to build open
source clients outside of the perils of the JS runtime.

Edited to add: If anyone is interested in building such a open source desktop
client in Python, I could help by making our (SpiderOak's) toolchains,
packagers, and installers available.

Edited again to add: Assuming a solid design and implementation is eventually
produced in Javascript, you could probably re-use most of the code and avoid
the JS runtime dangers by repackaging it as a desktop app with something like
<http://appjs.org/> Remember that of course your privacy is based not just on
you using a secure client, but everyone you share data with doing likewise.

~~~
mynegation
Paying customer here, thank you for a wonderful product and service!

One question I have is why SpiderOak client is not open-source? As I
understand, it is Python and decompiling it for analysis is not too much
trouble, but still...

~~~
rarrrrrr
Thanks for your interest in SpiderOak! Indeed we will open source the
SpiderOak desktop client one day. We've been saying that for a long time, but
we're very close. One of the reasons we haven't done so previously is how open
source products often get spammed with copycat repackagers, like the VLC guy
was explaining the other day.

I should also note that the crypto code in SpiderOak is in one specific
module, and we have repeatedly paid for careful audits of that code.

Lastly, we have a new crypto product in the works which we will announce at
RSA in February, which is 100% open source, and of particular interest to
developers in addition to SpiderOak customers. Please stay tuned!

~~~
thibaut_barrere
How do I stay tuned?

Is there a form somewhere to leave my email?

Thanks!

~~~
SkyMarshal
<https://spideroak.com/blog/>

Or RSS, Twitter, FB, or create a free account for email updates.

------
jakozaur
I just wonder how much Mega would have to pay to get all of those advices...

Now it gets all of them for free and likely it would use them to harden the
service.

~~~
bytex64
Release early, release often works pretty well when the whole world is waiting
for you to make a mistake. They are certainly getting a lot of valuable advice
for free.

It would have been better for their users, however, if they'd tried to get
this right before releasing. Mega smells very much like marketing over
technology.

------
SODaniel
I can't help but look at 'Mega' and get the feeling that the 'Secure and
Private' part is 99% Kim trying to protect himself from further lawsuits,
rather then actually ensuring the privacy and security of user data. I hope
I'm wrong of course.

~~~
rarrrrrr
IMO, if he primarily wanted to protect himself from further lawsuits he'd pick
a different line of business. There are easier ways to make money.

~~~
SODaniel
I would agree, if it wasn't for the fact that for him to start a 'somewhat
edgy storage service' guarantees him publicity, investors and the love of 10s
of millions of Megaupload users (and probably a few nice millions of $$ no
matter the outcome)

------
ostensibly
A pretty decent read, the code excerpts were pretty eye opening in context. I
wonder about the mentioned follow ups, especially the convergent encryption
server side. Dotcom's strategy just doesn't seem fixable with some of the
flaws in design. I'm new to the concept of js crypto, so it's interesting to
see how much has already been considered.

------
jules
> A "salt" is a small random value used to vary KDF output with the same
> password input. No salt means that any two users with the same passphrase
> will have the same KDF output.

Where would you get this salt from on the client side? That salt has to be the
same every time a user tries to access their data from a different computer,
otherwise you wouldn't be able to decrypt your files with the derived key
right? So how is this salt magically transferred from one computer to another?
The alternative is that you get the salt from the server along with the
encrypted file, but then I don't see how that improves security. Or perhaps
what I'm saying here is pure nonsense, in that case I'd very much appreciate a
clarification.

~~~
rarrrrrr
Great question. In the recommendations, we're suggesting using two salts. One
for deriving the key, and one just for challenges. Both of them are stored
plaintext on the server. The salt itself does not need to be kept secret --
it's purpose is just to mitigate pre-computation attacks on the password and
the resulting derived key.

Both salts are created by the client from random data at the time the account
is created, and saved to the server. So when a user wants to authenticate, you
can just give them the plaintext of the challenge salt along with the issued
challenge. There's no harm since it's just random data and shouldn't help them
to calculate an answer to the challenge if they don't know the pass phrase.
(Note that you only give them the challenge salt, not both salts.)

If you want the server to avoid disclosing the existence/non-existence of an
account with a particular name (wise!) then just give them a made up random
string as a challenge for non-existent accounts. Cache it somewhere so you can
be consistent. Always rate limit login attempts.

Hope that makes more sense. :)

~~~
jules
It does so far, and I see how this does no harm (as you say), but I also don't
see how it improves security? Can you give an attack that would work against
the unsalted system which wouldn't work against the salted system?

~~~
rarrrrrr
The key derivation function's purpose is to take a long time (CPU time) to
compute an output key given a password input. The combination of dangers here
is that the KDF is too fast (doesn't take enough CPU) AND the output is the
same per user.

What we're trying to protect against is someone in possession of the data
(such as Mega themselves, or anyone working for them, or hacking them, or
seizing their assets, or just someone over the internet making an offline
attempt against an account after discovering the auth hash) from making a
brute force attempt to learn the plaintext content of the accounts.

So to help me crack accounts, I could make a database of outputs from the KDF,
with every password combination pre-computed. "Start with "aaaaaa" as a
password, and go all the way through "ZZZZZZ" out to some number of
characters. The database would have 32 output bytes per entry. The first 32
bytes would be the output of "aaaaaa" through the kdf, then "aaaaab", and so
on.

If my math is right, going out to 6 characters using letters numbers and
punctuation, the database (probably just a file really) would be about 5 TB in
length, and based on my single slow CPU's AES speed, would take about 99 CPU
days to compute. Of course if you have 100 CPUs (or EC2, or a botnet) you
could have it done in time for dinner tomorrow. Or just wait because someone
will likely precompute one you can bittorrent in the next few days.

So, if I wanted to make a brute force attack against Mega's database of users,
I would use this pre-computed database, reading it sequentially from disk,
taking every 32 byte section and trying it as a key to decrypt the next layer
of keys for a user. My CPU could likely check answers faster than the data
would stream in from the disk.

So I would be able to brute force any combination out to 6 password characters
in a few minutes using only the spare hardware sitting around my office and
unoptimized code. Imagine what NSA could do.

So, finally getting back to answering your question. If the salt were used,
then I couldn't pre-compute the KDF output. I would have to do it separately
for each user. So then my attempts would (again on my weak CPU) proceed at
only about 520 attempts per second. That's still about 500 times to fast. So,
the design needs both a slower KDF, and salt. :)

Trivia: Want to time your own CPU and how many AES cycles it can do?

    
    
      $ openssl speed -evp aes-128-ecb 
      Doing aes-128-ecb for 3s on 16 size blocks: 102358287 aes-128-ecb's in 3.00s 
      >>> 102358287 / 3 / 2**16 
      520
    

Hopefully that makes sense!

~~~
jules
Well it kinda does make sense but I don't understand why you would go through
this trouble with sending salts around. If the goal is what you describe
couldn't you just derive a salt from the username at the client side? (I was
assuming that they were already doing this, but apparently they are not?)

~~~
jfarmer
The higher the entropy of the salt the better.

Let's say everyone did as you propose and use usernames for salts. I could
pre-compute dictionaries for usernames like root, admin, etc. and likely gain
full access to a wide range of systems.

Our aim is to build a system where brute-forcing is always the cheapest
option. Once that's the case, we're in a position to control "how expensive"
it is for someone to invert even one derived key.

~~~
jules
Presumably each username on Mega is unique, so that precomputation won't give
you anything.

~~~
jiggy2011
Perhaps the point is to reduce the risk that a rainbow table already created
for some other use could be used in this case?

~~~
jules
That would at most reduce the number of KDF calls an attacker would need to
perform by a factor of 2, if (1) the other service is using exactly the same
KDF (2) all the usernames are identical in the two services. If not all the
usernames are identical, then the factor of 2 is even lower. If an attacker
can perform n calls to a KDF then he can also perform 2n calls to it, so if
you're relying on that factor of 2 for security you have a problem no matter
what. In any case this is easily defeated by adding a random string:
KDF(username + "|blablafoo|" + password).

~~~
jiggy2011
Yes, this would be true in the case of adding a random string as a second salt
but then this would have to be sent to the client also.

I am not sufficiently familiar with KDFs but I know that rainbow tables exist
to crack straight up md5 hashed passwords for common usernames and passwords
where the username has been used as the salt.

Maybe harder to do with a KDF because it's prohibitive to compute that many
keys in the first place?

------
redthrowaway
A small point, but the title here might bear changing. "Crypto analysis"
suggests a typo of "cryptanalysis", which is not what the article is about.
Perhaps "Analysis and Recommendations for the Crypto in Mega" might be a
better title.

------
ragenz
I just wish spideroak had a easy to use and registration free service like
mega.

Well, the w3c is creating a recommendation for js crypto APIs, so maybe we'll
soon see more services like this.

~~~
rarrrrrr
I wish we could too, but instead we rely on the time honored approach of
charging our customers directly for our services, rather than trying to
monetize with advertising or selling your data. We do offer 2GB for free for
life though. Thanks for your interest regardless!

~~~
pppp
I used spideroak for a year (paid) and slowly grew to hate the client.
Everthing else about the service was great and I had a large amount of trust
in the company, but the client was extremely slow and unpredictable.

I wish Dropbox and SpiderOak would mate and have a child product that was as
smooth, fast and easy to use as Dropbox, but with full SpiderOak grade client
side encryption.

------
eps
The most interesting part of this whole Mega Crypto drama is if Mega would in
fact straighten their implementation, or if it was perhaps made bruteforce-
able by design.

~~~
bytex64
I tend to trust in incompetence over conspiracy. With Kim Dotcom, though, who
knows?

~~~
gizmo686
What would Dotcom gain from having a weak crypto system. Plausible deniabilty
will work up to a point, but the government can still subpoena his encrypted
data, crack it themselves, then require Dotcom to comply. And if Dotcom
actually acted (or even accessed) the data, then he would through plausible
deniabilty out of the window by demonstrating that he does have access to the
data, in which case the entire exersise in creating the cryptosystem is
pointless.

~~~
eps
He _might_ gain easier sharing and (much) more traffic.

