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.
Megabad: A quick look at the state of Mega’s encryption
21–30 of 60 posts
Re: Megabad: A quick look at the state of Mega’s encryption
#22I'm most curious to find out more about the de-duplication issue. Could this be a carry-over from their previous ToS where someone just didn't put 2 and 2 together? How could they de-dupe stuff without knowing what it is in the first place?
If the client (your browser in this case) sends a hash of file chunks before it encrypts and uploads the data you could do deduplication without having the actual decrypted data.
But both clients still need to be able to decrypt it with their separate keys... even if the cleartext hash matches, the stored data is ciphertext and can only be encrypted with one user's key.
Re: Megabad: A quick look at the state of Mega’s encryption
#23> [...] the implication is that a uniquely identifiable thing can be derived from any given piece of data. This returns some burden to Mega—rather than throw up its hands and say that it has no idea what Mega users Alice or Bob have in their Mega accounts, there apparently is a way of telling whether or not Bob and Alice have the same file or files. If the MPAA gets wind that Bob is hosting a copy of The Hobbit: An U…
It sounds to me like Mega is just using block-level hardware de-duplication and they're making sure it's clearly spelled out in the Terms.
After all, if each file is being encrypted with different keys, then Alice and Bob's encrypted copies of THE HOBBIT wouldn't match at all. So much as removing the file from Mega's servers and re-uploading it would seemingly change the key and thus the encrypted data entirely, right?
And when encrypted blocks do happen to match, there'd be absolutely no way of knowing whether they represent the same block of the same source file. In fact, one could be reasonably confident that a block overlap was purely incidental, given the random unique keys. (barring completely broken key generation)
Re: Megabad: A quick look at the state of Mega’s encryption
#24JavaScript security is really the best way to go for this type of service. At some point there needs to be a trade-off between the application goals and maximum theoretical security.
Chrome has native crypto.getRandomValues() and Safari's Math.random() was changed to use Arc4 PRNG back in 2008. I'm not sure if it has been updated to account for the flaws in the first bytes of Arc4, but if it has then this is cryptographically strong.
I don't know where Firefox and the other browsers stand on CSPRNGs, but as more and more implement crypto.getRandomValues(), this will improve services relying on client-side crypto.
Re: Megabad: A quick look at the state of Mega’s encryption
#25I said this on the last thread about Mega. I'm fairly sure that the encryption is not to protect your data from them and others, its to protect them from your data by giving them an optionality to deny any knowledge of what they are hosting. It is in there interest to do de-duplication and as they are still required to remove files under the DMCA it will just mean that multiple people loose there infringing files at…
Was about to state the same. The encryption is Dotcom's shield against future lawsuits toward himself or Mega. The simple fact that it is technically 'impossible' to know what users store on their servers protect them from the megaupload situation happening once again. As read elsewhere, do not store any confidential file on mega: the encryption does not protect the user, but the platform itself.
Essentially, MEGA is future-proof. In this political climate, I'll take it.
Re: Megabad: A quick look at the state of Mega’s encryption
#26Earlier quoted context omitted.
You're not missing anything. I clenched my teeth when I red this phrase. It doesn't mean anything and discredits the whole article as it shows the author has got a superficial knowledge in cryptography.
Generating RSA keys with math.Random is clown crypto, though.
Is it clown-crypto from the point of view of creating plausible deniability for Mega, or only from the point of view of keeping what your uploading secret from Mega? Genuine question.
Re: Megabad: A quick look at the state of Mega’s encryption
#27I think that infringement protection can be handled using the following scheme:
User uploads file. Mega computes the convergent encryption E(F) using the hash of the file H(F). The hash of E(F) is H(E(F)) and determines the file already exists in Mega, and thus is deduplicated.
Mega does not tell the user this, and their used storage size increases (thus, RIAA cannot upload The Hobbit and determine it's already there). The user enters their password P, the convergent hash H(E(F)) is encrypted with the user's password - P(H(E(F))) - and is only stored correlated with the user as such. The hash of the original H(F) (used to convergently encrypt the file) is also encrypted with the user's password, as P(H(F)).
On retrieval, the user enters their password P, the hash P(H(E(F))) and the hash of the original P(H(F)) is decrypted. Now Mega knows where to find the convergently encrypted file, using H(E(F)) to locate E(F). Mega decrypts using the hash of the original, and returns the file F to the user.
If the password P is only stored hashed (as it should!), then there is no way to correlate a given infringing file with any other user's ownership. The user's account only contains P(H(E(F))) and P(H(F)), both of which are unique to that user.
Anyone see a problem (other than the implementation details and possible lack of motivation for Mega to do so)?
Re: Megabad: A quick look at the state of Mega’s encryption
#28I said this on the last thread about Mega. I'm fairly sure that the encryption is not to protect your data from them and others, its to protect them from your data by giving them an optionality to deny any knowledge of what they are hosting. It is in there interest to do de-duplication and as they are still required to remove files under the DMCA it will just mean that multiple people loose there infringing files at…
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 it.
If every copy of THEHOBBIT.mp4 resulted in the same data after it was encrypted, if it was a predictable transformation, I don't see how any court would give Mega a pass for not 'knowing' what the contents of an uploaded file were. They'd not only know they'd be explicitly generating a fingerprint of that unique file in creating the encrypted version. It'd be irrelevant as a legal shield.
Re: Megabad: A quick look at the state of Mega’s encryption
#29> [...] the implication is that a uniquely identifiable thing can be derived from any given piece of data. This returns some burden to Mega—rather than throw up its hands and say that it has no idea what Mega users Alice or Bob have in their Mega accounts, there apparently is a way of telling whether or not Bob and Alice have the same file or files. If the MPAA gets wind that Bob is hosting a copy of The Hobbit: An U…
It sounds to me like Mega is just using block-level hardware de-duplication and they're making sure it's clearly spelled out in the Terms. After all, if each file is being encrypted with different keys, then Alice and Bob's encrypted copies of THE HOBBIT wouldn't match at all. So much as removing the file from Mega's servers and re-uploading it would seemingly change the key and thus the encrypted data entirely, righ…
> After all, if each file is being encrypted with different keys, then Alice and Bob's encrypted copies of THE HOBBIT wouldn't match at all. So much as removing the file from Mega's servers and re-uploading it would seemingly change the key and thus the encrypted data entirely, right?
As far as I can tell, they're generating the keys for the files from a hash of the file, meaning the keys are not random and unique (for the files -- user keys are different). I described rough steps for secure dedupe in another comment below.
Re: Megabad: A quick look at the state of Mega’s encryption
#30I think that infringement protection can be handled using the following scheme: User uploads file. Mega computes the convergent encryption E(F) using the hash of the file H(F). The hash of E(F) is H(E(F)) and determines the file already exists in Mega, and thus is deduplicated. Mega does not tell the user this, and their used storage size increases (thus, RIAA cannot upload The Hobbit and determine it's already there…
This. I was thinking of exactly this solution while reading this whole discussion but was unable to express it clearly.
Basically, if a user's 'tree' is encrypted with his password, I don't think anyone can identify who has a particular file. It does allow to revoke the file for everyone in one operation though.