Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crypto Analysis and Recommendations for Mega

spideroak.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Crypto Analysis and Recommendations for Mega

#21

Post by rarrrrrr »

jules wrote: post #18

> 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 ho…

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

Re: Crypto Analysis and Recommendations for Mega

#22

Post by jules »

rarrrrrr wrote: post #21
jules wrote: post #18

> 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 ho…

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 create…

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?

Re: Crypto Analysis and Recommendations for Mega

#23

Post by diminoten »

bytex64 wrote: post #14
eps wrote: post #12

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.

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

All this hate for Kim Dotcom aside, he didn't literally write it, some developer did, and if that developer is anything like me, he's going to want to take care of his baby, and these recommendations are going to immensely help him do that.

But he might not be like me, so I dunno.

Re: Crypto Analysis and Recommendations for Mega

#25

Post by jfarmer »

jules wrote: post #22
rarrrrrr wrote: post #21

Earlier quoted context omitted.

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 create…

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?

Without a salt one can pre-compute all the KDF (input, output) pairs and store them in a dictionary (essentially). This single dictionary now acts as a kind of master key.

By including a random per-user salt, even assuming the attacker has access to the salt, the output of the KDF now varies on both a per-user and per-password basis.

Two users with the same password have different keys under this design, so pre-computing something that works for all users becomes infeasible.

If the KDF is weak in other ways, e.g., it is so fast that one doesn't need to pre-compute anything, that's a separate issue.

Re: Crypto Analysis and Recommendations for Mega

#26

Post by dmix »

SODaniel wrote: post #9

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.

This exact comment has come up in every single Mega thread.

Re: Crypto Analysis and Recommendations for Mega

#27

Post by SkyMarshal »

thibaut_barrere wrote: post #17
rarrrrrr wrote: post #11

Earlier quoted context omitted.

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…

How do I stay tuned? Is there a form somewhere to leave my email? Thanks!

https://spideroak.com/blog/

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

Re: Crypto Analysis and Recommendations for Mega

#28

Post by rarrrrrr »

ragenz wrote: post #24

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.

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!

Re: Crypto Analysis and Recommendations for Mega

#29

Post by ww520 »

jules wrote: post #22
rarrrrrr wrote: post #21

Earlier quoted context omitted.

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 create…

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?

In a unsalted system, let's say your password is "hello" and my password is "hello." Your hash("hello") will be same as my hash("hello"). When I see your hash is same as mine, I know your password is "hello."

In a salted system, your hash("hello" + salt1) != my hash("hello" + salt2), and I have no way of guessing your password since the hashes are different.

Re: Crypto Analysis and Recommendations for Mega

#30

Post by gizmo686 »

SODaniel wrote: post #9

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.

Does it matter? In this case the alterior motive (Kim protecting himself) happens to coincide with privacy, becuase if your information was not private than Mega could know it, which defeats the entire point of Mega being protected by not knowing it.
Post reply on HN