8 ms·

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

57 points by qubitsam 14y ago

jiggy2011 14y ago
"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.
- thirsteh 14y ago
  It's not true. And yes, for equivalent bits of security, you need much larger keys with the RSA algorithm. The main reason it's not used for much beyond key-exchange is that it's thus exponentially slower.
EwanG 14y ago
A rather good write-up, though I'm not convinced the author's points justify the "Megabad" in the title. The decisions made are not always the most secure, but in general appear to be reasonable given the nature of the service - i.e. that this is material meant to be shared not just backed up.
- dewey 14y ago
  Indeed, by just reading the title I thought the encryption is already broken and useless. It's just a filesharing site and not a secure and personal backup space. (I'm sure some guys will use it as their only backup like it was happening with MU though).
  - aw3c2 14y ago
    They advertise themselves as "THE PRIVACY COMPANY". Any problems with that image should be exposed and shamed.
sbarre 14y ago
I'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?
- tlack 14y ago
  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.
  - wmf 14y ago
    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.)
    - daeken 14y ago
      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 file, the only things that differ are key U and key X -- these are his user key, and his user key for the data. That means that Mega can deduplicate file C freely, because they're identical. Note that Mega never knows the hash of the original file -- key K -- or it'd be able to decrypt the files.
      - jiggy2011 14y ago
        "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".
simias 14y ago
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, unless I'm missing something.
- tptacek 14y ago
  Block ciphers are not "less secure" than RSA. If anything, the opposite is true. You can ignore this part of the article.
- shin_lao 14y ago
  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.
  - tptacek 14y ago
    Generating RSA keys with math.Random is clown crypto, though.
    - simias 14y ago
      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?
      - daeken 14y ago
        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.
samwillis 14y ago
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 once. All someone then needs to do to upload the file again is change one byte. The encryption also stops them from being able to implement a back door for the content industry to police the site themselves as was the case with megaupload.
- moystard 14y ago
  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.
  - thoughtcriminal 14y ago
    Essentially, MEGA is future-proof. In this political climate, I'll take it.
- roc 14y ago
  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.
daeken 14y ago
> [...] 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 Unexpectedly Long Movie in his Mega folder, and Alice also happens to have the same file in her Mega folder, it's trivial to prove that Alice has the same file—in fact, the nature of deduplication means there's some record of every deduplicated block, and therefore every other infringing user. This actually doesn't follow at all. What files a given user has in their account doesn't have to be known to the server, though it's generally not difficult to correlate gets/puts/deletes to accounts. If the hierarchy is handled on the client side and encrypted like everything else, then all the server knows is: we store blobs identified by keys, and when those keys are overlapping, we don't need to store a second copy. This does make keeping track of storage usage impossible.
- roc 14y ago
  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)
  - daeken 14y ago
    > 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.
krallin 14y ago
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 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. Asymmetric encryption is not appropriate for encryption of large amounts of data (or would require incredibly large keys to work). Symmetric encryption is always used to encrypt large chunks of data, and asymmetric encryption can be used to encrypt a symmetric key. The article seems to hint that Mega was lazy in its implementation, that's not really true. > For the data stored in Mega, the encryption key used is generated for you at the time of sign-up and is itself hashed—or scrambled—using your account's password. The key can't be hashed, or it couldn't be recovered. A hash is meant to be un-reversible. Unless the article means that the key itself is a derivation (a hash?) of the password. This would indeed be a major issue! If the key is encrypted using the password (hopefully after running it trough a PBKDF), it is fine. The absence of a password change option is indeed worrying, but the absence of a password recovery option is reassuring. If you lose your password, then you lose the ability to decrypt your key. If you lose your ability to decrypt your key, you lose your data. It indeed is problematic that you can't back up the key though!
- el_cuadrado 14y ago
  > 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.
  - krallin 14y ago
    In this specific case it wouldn't be very practical as changing the password would mean changing the encryption key to all your files. Hence, rendering all files unreadable. That's why I suggested that a more appropriate application would be to derive a key from the password (using a PBKDF, which PKCS5 is (PBKDF2)) and use that one to encrypt the file encryption key. This way, you can always change the password (provided you still have it) and encrypt the encryption key again, while not needing to encrypt each file.
B-Con 14y ago
> Unfortunately for Mega, it's generating the RSA keys with Javascript, and the method employed doesn't do a very good job at all of capturing entropy. I think that the vast majority of security experts advise that none of the crypto should be done in JavaScript, especially key generation. But I'm guessing they wanted to do it that way so that the key generation is done on the client side. They could generate high-quality keys on their servers through the normal means of doing so, but then they have access to all user's private keys, and part of the point of this service is that the users don't want to trust the service (ie, Mega). Thus they decided to generate keys on the client, but probably had to debate whether they wanted to get Java involved or not. (Java applets, as far as I know, would be able to access the system's native entropy pools for good quality entropy.) For simplicity and ease-of-use, perhaps they decided to avoid Java. They are probably also anticipating the release of native crypto libraries in JavaScript in the relatively near future, which would likely include access to system entropy, and so they may consider this a somewhat short-term problem.
- thirsteh 14y ago
  Indeed. This is the Web Crypto API. It includes access to a CSPRNG: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/
rfugger 14y ago
Rather than "megabad", Mega's crypto scheme actually seems pretty reasonable given their desire to do it all in-browser.
revelation 14y ago
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.
- bascule 14y ago
  window.crypto.random() will be able to do this once WebCrypto has widespread adoption
amper5and 14y ago
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 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.
- rarrrrrr 14y ago
  For Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=322529 https://bugzilla.mozilla.org/show_bug.cgi?id=322529
cmurphycode 14y ago
I 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)?
- leddt 14y ago
  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.
Uchikoma 14y ago
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."
- bascule 14y ago
  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.

57 points by qubitsam 14y ago

jiggy2011 14y ago

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

thirsteh 14y ago
It's not true. And yes, for equivalent bits of security, you need much larger keys with the RSA algorithm. The main reason it's not used for much beyond key-exchange is that it's thus exponentially slower.

EwanG 14y ago

A rather good write-up, though I'm not convinced the author's points justify the "Megabad" in the title. The decisions made are not always the most secure, but in general appear to be reasonable given the nature of the service - i.e. that this is material meant to be shared not just backed up.

dewey 14y ago
Indeed, by just reading the title I thought the encryption is already broken and useless. It's just a filesharing site and not a secure and personal backup space. (I'm sure some guys will use it as their only backup like it was happening with MU though).
- aw3c2 14y ago
  They advertise themselves as "THE PRIVACY COMPANY". Any problems with that image should be exposed and shamed.

sbarre 14y ago

I'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?

tlack 14y ago
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.
- wmf 14y ago
  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.)
  - daeken 14y ago
    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 file, the only things that differ are key U and key X -- these are his user key, and his user key for the data. That means that Mega can deduplicate file C freely, because they're identical. Note that Mega never knows the hash of the original file -- key K -- or it'd be able to decrypt the files.
    - jiggy2011 14y ago
      "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".

simias 14y ago

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, unless I'm missing something.

tptacek 14y ago
Block ciphers are not "less secure" than RSA. If anything, the opposite is true. You can ignore this part of the article.
shin_lao 14y ago
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.
- tptacek 14y ago
  Generating RSA keys with math.Random is clown crypto, though.
  - simias 14y ago
    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?
    - daeken 14y ago
      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.

samwillis 14y ago

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 once. All someone then needs to do to upload the file again is change one byte. The encryption also stops them from being able to implement a back door for the content industry to police the site themselves as was the case with megaupload.

moystard 14y ago
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.
- thoughtcriminal 14y ago
  Essentially, MEGA is future-proof. In this political climate, I'll take it.
roc 14y ago
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.

daeken 14y ago

> [...] 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 Unexpectedly Long Movie in his Mega folder, and Alice also happens to have the same file in her Mega folder, it's trivial to prove that Alice has the same file—in fact, the nature of deduplication means there's some record of every deduplicated block, and therefore every other infringing user. This actually doesn't follow at all. What files a given user has in their account doesn't have to be known to the server, though it's generally not difficult to correlate gets/puts/deletes to accounts. If the hierarchy is handled on the client side and encrypted like everything else, then all the server knows is: we store blobs identified by keys, and when those keys are overlapping, we don't need to store a second copy. This does make keeping track of storage usage impossible.

roc 14y ago
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)
- daeken 14y ago
  > 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.

krallin 14y ago

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 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. Asymmetric encryption is not appropriate for encryption of large amounts of data (or would require incredibly large keys to work). Symmetric encryption is always used to encrypt large chunks of data, and asymmetric encryption can be used to encrypt a symmetric key. The article seems to hint that Mega was lazy in its implementation, that's not really true. > For the data stored in Mega, the encryption key used is generated for you at the time of sign-up and is itself hashed—or scrambled—using your account's password. The key can't be hashed, or it couldn't be recovered. A hash is meant to be un-reversible. Unless the article means that the key itself is a derivation (a hash?) of the password. This would indeed be a major issue! If the key is encrypted using the password (hopefully after running it trough a PBKDF), it is fine. The absence of a password change option is indeed worrying, but the absence of a password recovery option is reassuring. If you lose your password, then you lose the ability to decrypt your key. If you lose your ability to decrypt your key, you lose your data. It indeed is problematic that you can't back up the key though!

el_cuadrado 14y ago
> 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.
- krallin 14y ago
  In this specific case it wouldn't be very practical as changing the password would mean changing the encryption key to all your files. Hence, rendering all files unreadable. That's why I suggested that a more appropriate application would be to derive a key from the password (using a PBKDF, which PKCS5 is (PBKDF2)) and use that one to encrypt the file encryption key. This way, you can always change the password (provided you still have it) and encrypt the encryption key again, while not needing to encrypt each file.

B-Con 14y ago

> Unfortunately for Mega, it's generating the RSA keys with Javascript, and the method employed doesn't do a very good job at all of capturing entropy. I think that the vast majority of security experts advise that none of the crypto should be done in JavaScript, especially key generation. But I'm guessing they wanted to do it that way so that the key generation is done on the client side. They could generate high-quality keys on their servers through the normal means of doing so, but then they have access to all user's private keys, and part of the point of this service is that the users don't want to trust the service (ie, Mega). Thus they decided to generate keys on the client, but probably had to debate whether they wanted to get Java involved or not. (Java applets, as far as I know, would be able to access the system's native entropy pools for good quality entropy.) For simplicity and ease-of-use, perhaps they decided to avoid Java. They are probably also anticipating the release of native crypto libraries in JavaScript in the relatively near future, which would likely include access to system entropy, and so they may consider this a somewhat short-term problem.

thirsteh 14y ago
Indeed. This is the Web Crypto API. It includes access to a CSPRNG: http://www.w3.org/TR/WebCryptoAPI/ http://www.w3.org/TR/WebCryptoAPI/

rfugger 14y ago

Rather than "megabad", Mega's crypto scheme actually seems pretty reasonable given their desire to do it all in-browser.

revelation 14y ago

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.

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

amper5and 14y ago

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

rarrrrrr 14y ago
For Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=322529 https://bugzilla.mozilla.org/show_bug.cgi?id=322529

cmurphycode 14y ago

I 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)?

leddt 14y ago
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.

Uchikoma 14y ago

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

bascule 14y ago
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.