Megabad: A quick look at the state of Mega’s encryption • Hacker News Board

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

#31

Post by B-Con » Mon, Jan 21, 2013, 5:20 PM UTC

loeg wrote: post #22

tlack wrote: post #5

Earlier quoted context omitted.

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.

It's possible: http://crypto.stackexchange.com/questions/729/is-convergent-... .

The trick lies in ensuring the key used for encryption is linked to the file, not the user. You then have to store a separate key for each encrypted file (and that encryption key is probably going to need to be wrapped by your actual user key for storage).

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

#32

Post by rarrrrrr » Mon, Jan 21, 2013, 5:21 PM UTC

amper5and wrote: post #24

JavaScript 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 cryptogr…

For Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=322529

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

#33

Post by roc » Mon, Jan 21, 2013, 5:28 PM UTC

daeken wrote: post #29

roc wrote: post #23

Earlier quoted context omitted.

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 (f…

Then the encryption isn't worth the processing time. And as a 'legal shield' it seems like it will not only be utterly ineffective in court, but it's going to be cited as proof of Mega's ability to know what people are hosting, due their generation of a file fingerprint as a matter of course.

They're going to wind up having to maintain a hash blacklist which is going to be just annoying enough that people aren't going to bother.

It's a shame mega isn't just running an encrypted block-level store. They should have shipped client binaries that handle the encryption and key generation and simply exchanged blocks with Mega servers.

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

#34

Post by B-Con » Mon, Jan 21, 2013, 5:30 PM UTC

roc wrote: post #28

samwillis wrote: post #10

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

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

#35

Post by visarga » Mon, Jan 21, 2013, 5:32 PM UTC

roc wrote: post #28

samwillis wrote: post #10

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

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

#36

Post by DoubleMalt » Mon, Jan 21, 2013, 5:32 PM UTC

simias wrote: post #4

I don't understand that part: Symmetric encryption means the same key is used to encrypt and decrypt your data; this is less secure than asymmetric encryption (where one key encrypts and a different key decrypts), but it's faster and easier to implement. Isn't that comparing apples to oranges? What would be the benefit for Mega or the user to switch to RSA for that? Encryption would be using a symmetric cipher anyway…

I stopped reading the article right there. This shows such a blatant misunderstanding of encryption that it's not even funny any more.

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

#37

Post by jerf » Mon, Jan 21, 2013, 5:40 PM UTC

roc wrote: post #23

daeken wrote: post #12

> [...] 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…

No, it's the other way around; a block overlap is effectively a guarantee it's the same file with the same key.

Suppose they are using 1MB chunks. The keys are 16 bytes. The 1MB chunk may be 2 ^ (8 millionish) different things, the keys only 2^128 different things. Thus, two different 1MB chunks, to be the same file with different keys, must have two of their possible 2^128[1] encryptions overlap out of the possibility space of 2^(8 millionish); that any two different chunks would even have such an overlap available is exceedingly, exceedingly improbable, let alone that the two users would end up with the exact correct keys to have actually manifested the overlap.

There are only two plausible theories when an overlap occurs: 1. It is the same file with the same key or 2. Someone's worked out how to artificially create a collision. And those two are hardly equal in probability either....

[1]: Yeah, that's a simplification since there aren't actually 2^128 valid keys. Roll with it. Actually I've taken a number of small liberties for simplicity; none of them matter.

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

#38

Post by el_cuadrado » Mon, Jan 21, 2013, 5:47 PM UTC

krallin wrote: post #14

The first part of the article is of unusually low quality for Ars Technica. It seems like the author is trying to bash Mega for being reportedly lazy in their implementation. This really is a shame because the parts regarding entropy, deduplication, and the conclusion, are very relevant! > Files and folders, therefore, are encrypted with symmetric encryption. Symmetric encryption means the same key is used to encrypt…

> Unless the article means that the key itself is a derivation (a hash?) of the password

Why is this an issue? Other people call this 'issue' PKCS5.

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

#39

Post by Uchikoma » Mon, Jan 21, 2013, 5:54 PM UTC

This is where Ars lost all credibility:

"Files and folders, therefore, are encrypted with symmetric encryption. Symmetric encryption means the same key is used to encrypt and decrypt your data; this is less secure than asymmetric encryption (where one key encrypts and a different key decrypts), but it's faster and easier to implement."

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

#40

Post by bascule » Mon, Jan 21, 2013, 5:57 PM UTC

Uchikoma wrote: post #39

This is where Ars lost all credibility: "Files and folders, therefore, are encrypted with symmetric encryption. Symmetric encryption means the same key is used to encrypt and decrypt your data; this is less secure than asymmetric encryption (where one key encrypts and a different key decrypts), but it's faster and easier to implement."

I just saw that and facepalmed as well. Beyond the sheer number of attacks you can perpetrate on RSA versus AES (never mind in the browser), MEGA is using 2048-bit RSA, which has a 112-bit security level, versus 128-bit AES.

Symmetric ciphers are used almost exclusively for the encryption of large files. They're more secure, faster, and easier to work with.