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

11–20 of 50 posts

Re: Crypto Analysis and Recommendations for Mega

#11

Post by rarrrrrr »

mynegation wrote: post #5
rarrrrrr wrote: post #2

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

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

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!

Re: Crypto Analysis and Recommendations for Mega

#13

Post by SODaniel »

bytex64 wrote: post #10
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.

Without real privacy, it doesn't protect him or his users.

True, but it does of course at least for some time work as marketing.

Re: Crypto Analysis and Recommendations for Mega

#15

Post by ostensibly »

bytex64 wrote: post #10
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.

Without real privacy, it doesn't protect him or his users.

Yeah, looking at the news I don't agree with the people claiming Mega is trying to protect itself above users. It just seems genuinely flawed. I don't know what good the service would be without working privacy for the users.

Re: Crypto Analysis and Recommendations for Mega

#17

Post by thibaut_barrere »

rarrrrrr wrote: post #11
mynegation wrote: post #5

Earlier quoted context omitted.

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

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!

Re: Crypto Analysis and Recommendations for Mega

#18

Post by 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.

Re: Crypto Analysis and Recommendations for Mega

#20

Post by zcid »

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…

In this case, I believe the [server provided] salt would be used solely as a precaution against rainbow tables, but there may be additional benefits of which I am unaware.
Post reply on HN