Share

Related Links

Top 5 Stories

News

Mega’s security put under the microscope; and Mega responds

23 January 2013

Following the razzmatazz at the launch of Dotcom’s new secure Mega file storage service over the weekend comes the expected analysis and criticism of its security. There are two primary areas of focus – the RSA key generation and an apparent deduplication process.

Mega claims to be ultra secure and private, but critics are already pointing to weaknesses and inconsistencies. For performance purposes the files are protected by symmetric AES 128 encryption, with the keys stored on Mega. The AES keys themselves are encrypted with 1024 bit RSA public/private keys generated and kept by the user. In theory that means that only the rightful user can decrypt the AES key to get access to the stored content.

Critics are focusing on the RSA key generation. It is generated in the user’s browser by Javascript using the math.random() function. Paul Ducklin, writing in the Sophos NakedSecurity blog, quotes John von Neumann who supposedly said, “Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin.” So put simply, Javascript on its own cannot produce genuine randomness. The math needs added entropy, which Mega attempts to provide by including random data from mouse and keyboard activity.

"To strengthen the key, we have collected entropy from your mouse movements and keystroke timings,” says Mega. “So, wait,” replies ArsTechnica, “should I wiggle my mouse now, or is it too late?”

Mega has responded by announcing yesterday, “We will, however, add a feature that allows the user to add as much entropy manually as he sees fit before proceeding to the key generation.”

The second criticism concerns apparent deduplication. Mega’s terms state that it ‘may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service.’ “Deduplication ought to be impossible,” says Ducklin. “Even if the duplicated content can't be retrieved, merely knowing that user A and user B have the same stuff is a privacy problem, because a leak by user A (or a confession to law enforcment) then turns into a leak for user B.”

“Whatever the underlying method,” adds ArsTechnica, “the fact that block deduplication exists is a blow against the ‘see no evil’ approach taken by Mega.” To this, Mega has responded, “MEGA indeed uses deduplication, but it does so based on the entire file post-encryption rather than on blocks pre-encryption.” The deduplication is thus aimed at users who share the same file between themselves, or keep multiple copies of the same file. It simply replaces copy 2 with a link to copy 1. Since it is performed post encryption, it doesn’t apply to multiple copies of The Hobbit uploaded by different users, it only applies to the same copy of The Hobbit shared or copied by the user concerned.

In reality, this criticism and response is exactly how security should work. Nothing is completely secure; but it is improved when queries are raised and responses provided. It is likely that there will be more criticisms; but the important part is how Mega responds.

This article is featured in:
Cloud Computing  •  Encryption  •  Internet and Network Security

 

Comment on this article

You must be registered and logged in to leave a comment about this article.

We use cookies to operate this website and to improve its usability. Full details of what cookies are, why we use them and how you can manage them can be found by reading our Privacy & Cookies page. Please note that by using this site you are consenting to the use of cookies. ×