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

Megabad: A quick look at the state of Mega’s encryption

arstechnica.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Megabad: A quick look at the state of Mega’s encryption

#41

Post by bluegate010 »

simias wrote: post #15
tptacek wrote: post #8

Earlier quoted context omitted.

Generating RSA keys with math.Random is clown crypto, though.

Isn't in-browser crypto clown crypto by definition though? After all, unless you audit all the code fetched each time you load the page, they can mess with the code client side at any moment without anybody noticing. Is this not more telling about the limits of webdev rather than the skills of Mega's coders?

That's what Mega seems to be doing in their initAll() function, although since it's being audited with Javascript, it's still insecure.

Re: Megabad: A quick look at the state of Mega’s encryption

#42

Post by bascule »

revelation wrote: post #21

The only thing that is Megabad in there is using math.random to generate random data for the RSA key generation. That means they are dependent on the browser vendor to provide a sufficiently good PRNG, now and in the future. Seems like it might have been wiser for them to implement one, though it might be difficult to get good sources of entropy from Javascript.

window.crypto.random() will be able to do this once WebCrypto has widespread adoption

Re: Megabad: A quick look at the state of Mega’s encryption

#43

Post by shin_lao »

daeken wrote: post #19
simias wrote: post #15

Earlier quoted context omitted.

Isn't in-browser crypto clown crypto by definition though? After all, unless you audit all the code fetched each time you load the page, they can mess with the code client side at any moment without anybody noticing. Is this not more telling about the limits of webdev rather than the skills of Mega's coders?

The trust model is inherently broken when doing crypto in the browser the way they are, since the code could be changed at any time. But that doesn't mean you shouldn't implement things properly outside of that.

What do you mean by the code could be changed at any time.

AFAIK this applies to any software.

Re: Megabad: A quick look at the state of Mega’s encryption

#44

Post by daeken »

shin_lao wrote: post #43
daeken wrote: post #19

Earlier quoted context omitted.

The trust model is inherently broken when doing crypto in the browser the way they are, since the code could be changed at any time. But that doesn't mean you shouldn't implement things properly outside of that.

What do you mean by the code could be changed at any time . AFAIK this applies to any software.

Every time you visit the website, the crypto code is brand new to you. A site that securely and safely encrypted your data yesterday might be sending keys to the server tomorrow. This is a problem that's fairly unique to doing crypto on the client side in the browser.

Re: Megabad: A quick look at the state of Mega’s encryption

#45

Post by jiggy2011 »

"Symmetric encryption means the same key is used to encrypt and decrypt your data; this is less secure than asymmetric encryption"

Wat?

If this is true, why does an RSA key have to be significantly longer than an AES key?

In fact in most implementations asymmetric crypto is not used for exchanging or storing data. It's used to exchange a key that can be used for symmetric crypto.

Re: Megabad: A quick look at the state of Mega’s encryption

#46

Post by [deleted] »

B-Con wrote: post #34
roc wrote: post #28

Earlier quoted context omitted.

If each file is getting it's own key, that is, if THEHOBBIT.mp4 properly generates a unique key each time it's uploaded by each user, would there even be much overlap in Alice's and Bob's file data as hosted on Mega? If the file blocks are being encrypted with a unique key before they're uploaded, you seemingly wouldn't have to alter any bytes of a file that got hit with a DMCA request. You'd just have to re-upload i…

When the signature is generated, they have no idea how close one file is to another file. So long as various copies of THEHOBBIT.mp4 continue to be uploaded, modified by just one byte, user will be able to evade detection, even if Mega keeps a "known bad" list of signatures.

[deleted]

Re: Megabad: A quick look at the state of Mega’s encryption

#47

Post by jiggy2011 »

daeken wrote: post #18
wmf wrote: post #11

Earlier quoted context omitted.

I'm not sure that would work either. If Alice encrypts a block with key A and uploads it, then Bob encrypts the same block with key B and uploads it and Mega only stores Alice's copy then Bob won't be able to decrypt his own data. (Edit: I'm talking about the proposal from previous threads of encrypting with a random key, not encrypting with the hash.)

That's not how it works, though. Rough steps for how a system like this can work (bearing in mind that Mega might be doing it entirely differently): 1) Alice takes file P and hashes it to produce key K 2) Alice encrypts file P with key K to produce file C 3) Alice encrypts key K with key U (her user key) to produce key X 4) Alice sends key X and file C to Mega for storage When Bob does the same steps on a matching fi…

"Each file and each folder node uses its own randomly generated 128 bit key. File nodes use the same key for the attribute block and the file data, plus a 64 bit random counter start value and a 64 bit meta MAC to verify the file's integrity."

This implies that it is not convergent, unless dedup is somehow done with the "Meta MAC".

Re: Megabad: A quick look at the state of Mega’s encryption

#48

Post by roc »

visarga wrote: post #35
roc wrote: post #28

Earlier quoted context omitted.

If each file is getting it's own key, that is, if THEHOBBIT.mp4 properly generates a unique key each time it's uploaded by each user, would there even be much overlap in Alice's and Bob's file data as hosted on Mega? If the file blocks are being encrypted with a unique key before they're uploaded, you seemingly wouldn't have to alter any bytes of a file that got hit with a DMCA request. You'd just have to re-upload i…

You can't have both data deduplication and protection from MAFIAA. Deduplication will sabotage the ability of the site to claim ignorance. Their clinging on deduplication proves they are not serious about anonymity and safety.

Block-level de-duplication doesn't require or imply knowledge of, or access to, decrypted file contents. It would be trivial to use de-duplication in a secure way. (though you're not going to reap nearly as much return from de-duplication of secure files, natch)

I'd agree that they're not serious, if it's true that they're deterministically generating encryption keys based on file hashes. But the de-duplication part has nothing to do with it.

Re: Megabad: A quick look at the state of Mega’s encryption

#49

Post by roc »

B-Con wrote: post #34
roc wrote: post #28

Earlier quoted context omitted.

If each file is getting it's own key, that is, if THEHOBBIT.mp4 properly generates a unique key each time it's uploaded by each user, would there even be much overlap in Alice's and Bob's file data as hosted on Mega? If the file blocks are being encrypted with a unique key before they're uploaded, you seemingly wouldn't have to alter any bytes of a file that got hit with a DMCA request. You'd just have to re-upload i…

When the signature is generated, they have no idea how close one file is to another file. So long as various copies of THEHOBBIT.mp4 continue to be uploaded, modified by just one byte, user will be able to evade detection, even if Mega keeps a "known bad" list of signatures.

The practice of having to create and share one-byte-different copies of files would be enough to kill this service for the users that Dotcom professes to be enabling, in thumbing his nose at the authorities.

The biggest user-facing problem with torrents today is that it takes too long to find 'the right' or 'good' files. Ones that aren't loaded up with malware, or mislabeled, or encoded poorly, etc. Having to push various one-byte-difference copies of files is going to explode the search problem for users. And, once found, 'good' files couldn't be popularized, lest they be pulled down. And once one user scored a 'good' file, they wouldn't be able to share it directly through the service to even known associates due that same universal blacklist.

The usability on such a system sounds like a wet-dream for driving people into the arms of for-pay alternatives.

Further, having a fingerprint on every file you upload is a direct violation of the marketing pitch of security and anonymity that Dotcom's making to the 'legit' crowd.

Consider if there were a security breach at a popular online service and a text file of compromised accounts released. The FBI could upload a copy and then subpoena Mega for information on every user who had that same copy.

Sure, people could alter their files themselves, but who wants to put up with that kind of cognitive overhead to prevent malicious prosecution/persecution?

Re: Megabad: A quick look at the state of Mega’s encryption

#50

Post by tptacek »

simias wrote: post #15
tptacek wrote: post #8

Earlier quoted context omitted.

Generating RSA keys with math.Random is clown crypto, though.

Isn't in-browser crypto clown crypto by definition though? After all, unless you audit all the code fetched each time you load the page, they can mess with the code client side at any moment without anybody noticing. Is this not more telling about the limits of webdev rather than the skills of Mega's coders?

There are smart people who disagree with me, like Ben Adida at Mozilla, but as a general rule yes, doing crypto inside a browser with Javascript is clownish.

I haven't studied what Mega is doing at all, nor am I ever planning to; my point is just that however badly written the article is, there is indeed evidence that there's bad crypto in this system.

Post reply on HN