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

41–50 of 50 posts

Re: Crypto Analysis and Recommendations for Mega

#41

Post by MikeCapone »

rarrrrrr wrote: post #36
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.

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.

Easier if you're starting from zero, but he already knows this way and a lot of his ego must be wrapped into this corner of the digital world. I don't believe he made an entirely rational cost/benefits decision with this.

Re: Crypto Analysis and Recommendations for Mega

#42

Post by SODaniel »

rarrrrrr wrote: post #36
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.

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.

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)

Re: Crypto Analysis and Recommendations for Mega

#43

Post by eps »

gizmo686 wrote: post #32
bytex64 wrote: post #14

Earlier quoted context omitted.

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

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…

He might gain easier sharing and (much) more traffic.

Re: Crypto Analysis and Recommendations for Mega

#44

Post by zurn »

rarrrrrr wrote: post #36
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.

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.

I'd guess avoiding lawsuits is secondary to his other motives, which aren't necessarily characterised by "make money fast, safely".

Re: Crypto Analysis and Recommendations for Mega

#45

Post by jiggy2011 »

jules wrote: post #40
jfarmer wrote: post #38

Earlier quoted context omitted.

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

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

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

Re: Crypto Analysis and Recommendations for Mega

#46

Post by jules »

jiggy2011 wrote: post #45
jules wrote: post #40

Earlier quoted context omitted.

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

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

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

Re: Crypto Analysis and Recommendations for Mega

#47

Post by jiggy2011 »

jules wrote: post #46
jiggy2011 wrote: post #45

Earlier quoted context omitted.

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

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…

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?

Re: Crypto Analysis and Recommendations for Mega

#48

Post by pppp »

rarrrrrr wrote: post #28
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!

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.

Re: Crypto Analysis and Recommendations for Mega

#49

Post by jfarmer »

jules wrote: post #40
jfarmer wrote: post #38

Earlier quoted context omitted.

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

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

Unique inside Mega, yes, but not globally.

Imagine if UNIX systems did as you propose. The rainbow table for the salt "root" would let me do plenty of damage.

Re: Crypto Analysis and Recommendations for Mega

#50

Post by fx5 »

rarrrrrr wrote: post #31
jules wrote: post #22

Earlier quoted context omitted.

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?

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

Good explanation! Hey, I have exactly the same cpu btw. :)
Post reply on HN