Blog Post

Where Kim Dotcom and Mega have the edge on Dropbox and

As a world (in)famous technologist with the literal last name “Dotcom,” Kim Dotcom is a man whose swag is matched only by the damages sought against him by the U.S. government. His filesharing site Megaupload was long the ire of record companies and movie studios, who say it was a massive and sprawling repository of pirated content.

If the accusations are true, it was one of the more successful pirate operations in history. At its peak, Megaupload saw approximately 7 percent of internet traffic and grossed over $150 million in annual revenue. But Megaupload’s incredible run ended in the fall of 2012 when the FBI forcefully took down the site and sought Kim’s extradition from New Zealand to face a litany of criminal charges.

Of course, you can’t expect to keep a guy with the last name Dotcom down, and sure enough he recently announced the relaunch of a Megaupload redux dubbed Mega. Only Mega is a security- and privacy-conscious file-sharing service that audaciously targets storage industry magnates like Dropbox and

And loathe as some of us may be to admit it, he just may be on to something. Mega differentiates itself by embracing client-side encryption: generating and storing the keys on a user’s local machine rather than encrypting everything in the cloud. The result of such client-side encryption is not only a far more secure product – and a security practice the industry should embrace – but a significant reduction in cost and legal liability for Mega and other cloud storage providers that use this architecture.

How Mega is different

Security is one of the biggest inhibitors to cloud adoption. Yielding sensitive data to a third party over the public internet continues to be a dealbreaker for many medium- to large-scale enterprises, with their desire for privacy and concerns of regulatory and legal exposure.

In the movement to the cloud, data is exposed at two points to attack or compromise: in-flight (when it is being transmitted over the security no-man’s land of the public internet) and at-rest (when it physically sits on servers within the cloud system). In both instances there are a myriad of threats that could allow that data to be stolen or compromised.

Mega employs cryptography to protect data in-flight and at-rest. Now by all means, using encryption to protect data in-flight isn’t really game changing. Similar to most security-conscious sites, Mega wraps communication between its users with Secure Socket Layer (SSL) encryption.

But Mega is unique in its approach to handling encryption at rest. Rather than encrypting and storing keys for a client’s data within Mega’s infrastructure, Mega pushes their cryptography back to their users. So Mega users encrypt their own data prior to sending it to Mega’s servers, and store keys locally such that even Mega can’t read their data – or be forced to yield it to authorities.

While this sounds like a feature tailored solely to the needs of a company that will frequently find itself at the end of a subpoena, the desire to have users keep their own keys and send data in the form of encrypted “ciphertext” (rather than unencrypted “plaintext)” is actually one shared by mainstream small businesses and enterprises alike.

Benefit for providers

Having cloud providers hold ciphertext and having users handle their own encryption and keep their own keys makes sense on both sides of the fence.

In an architecture where customers are responsible for their own encryption and key management, significant legal liabilities are lifted from the service provider. Customers would assume personal liability for the selection and correct implementation of encryption algorithms – a critical concern for compliance regulations like PCI-DSS that incorporate strict rules on cryptography.

By having their customers manage keys locally, service providers can also significantly reduce costs. Many modern PCs incorporate a Trusted Platform Module (TPM) – a hardware device that can safely store cryptographic keys for prolonged periods of time. Storing keys locally on a TPM is relatively costless for the customer, but safely storing keys en masse in the cloud requires the use of expensive key management servers.

The cost of encryption

Encryption is also still not a costless process. By pushing customers to encrypt and decypt their own data, cloud providers can also redirect the significant compute time required to handle cryptography towards providing a higher quality of service for their customers.

For customers, sending only ciphertext to the cloud and keeping keys locally has real benefits beyond peace of mind. If a cloud services provider is ever hacked, that customer’s data will be encrypted in a way that can’t be decrypted using its service provider’s security infrastructure. There’s no master database of passwords that an attacker can break into. Customer data on the service provider remains locked in ciphertext and encrypted using one of any number of symmetric key algorithms.

It’s important to note, though, that there are consequences for moving to a client-side encryption architecture. For instance, when customers send only ciphertext to the cloud, popular means of reducing the on-disk footprint of data such as deduplication (in short, a process where copies or parts of files are deleted and data is instead “pointed” towards a single instance) are generally rendered impossible.

It’s also important to note that, for the server to dedupe data encrypted by the client, the client must yield sensitive information about the plaintext at various points during its encryption. The fact that Mega seems to perform client-side encryption with deduplication is a red flag to many security cognoscenti, and may even be a sign that Mega has more visibility into its clients; data then it otherwise claims.

Holes in Mega’s strategy

Mega’s security infrastructure is far from perfect. Their decision to handle cryptography in browser-based Javascript has already earned wide-spread criticism, and due to implementation issues in how Mega creates keys for users,  hackers could work around encryption and access plaintext data (what’s called a “side-channel attack”).

Regardless, to give credit where it’s due, Kim Dotcom’s decision to push encryption to the client is an impressively forward-thinking maneuver that should be replicated by Dropbox and other cloud storage providers. Client-side encryption makes financial and legal sense for customers and service providers, helping to enable even regulatory compliance-bound customers to embrace cloud computing at scale.

Andrew “Andy” Manoske is an Associate at GGV Capital, a Sand Hill and Shanghai-based venture capital firm. Prior to GGV, he was a product manager at NetApp and managed the design of security features across the company’s entire product line. Follow him on Twitter @a2d2.

26 Responses to “Where Kim Dotcom and Mega have the edge on Dropbox and”

  1. Does anyone know what “store keys locally” means?

    Because as far as I can see, Mega is not locked to one computer, and the user has only one key – his password.

    What are these multiple ‘keys’? How are these stored locally if the user go to another computer and also login with only the user name and password?

  2. I really recommend you guys to try BoxCryptor ( It offers true client-side encryption because the software is always installed locally on the user’s device and the user keeps the control of the security of his data in any cloud. BoxCryptor works with all major cloud storage services and provides an independent source of trust where the cloud storage provider is not responsible for the encryption nor the secure handling of the keys (note: BoxCryptor has no access to the files). Mega’s security has various drawbacks which were discovered by security researchers in the past days such as weak random number generator, weak key derivation easy injection of wrong code, among others … so the combination of serious implementation flaws and the fact that you still have to put all your trust in Mega, as they will have your files and are in charge of the encryption, makes it a no-go to store sensitive files.

  3. Sandy Mckinnon

    Andy – If you are interested in scalable next-gen Key management – Please check out SkyKEY and SkyPIN from CertiVox – – they are currently in Las Vegas launching their SSO solution for the Parallels APS framework as part of the Parallels 2013 Summit – which will allow hosting vendors to offer their services federating the SSO from APS – and with CertiVox’s SkyKEY service handling all the key distribution and management – and SkyPIN giving simple secure multifactor authentication.

    It’s coming – you can try it currently at PrivateSky – they can provide this for all cloud & mobile services (including data in motion and at rest somewhere…) Check them out at RSA if you are going at the end of the month.

  4. You may have missed the point – I don’t think he has ever claimed to have invented client side encryption its been around for yonks – he has used it to indemnify Mega. If his users upload copyright or banned files and are caught by the FBI or local police, MEGA will willingly co-operate if served with a warrant or take-down notice. Mega has thousands of beta testers all trying to find bugs or crack the encryption and win 10,000 Euros. Kim Dotcom does not have a financial interest in MEGA nor is he even a director. His wife and the millionaire Tony Lentino are the majority share holders at the moment. AFTER it has been thoroughly beta tested.and all bugs & flaws etc are fixed and Megabox and Megakey have been launched &beta tested, he has clearly announced he plans to list it on the stock exchange..
    Kim Dotcom has been using Twitter and the media as market research, PR and beta testers reports and its cost him nothing – is that innovation or what?.

  5. npcomplete

    While client side encryption is nothing new, not storing or being responsible for the keys is still rare in the industry.

    Also, it is still possible to dedup with encryption, though much less effective. You will just be matching much more random material than deduping blocks of material sharing the same bits e.g. portions of the same text file.

  6. Michael Poole

    Everywhere I look, shills & poorly informed people trying to slander Dotcom and Mega while conveniently excluding the absolutely insane, illegal actions of the corrupt U.S. government.

  7. What do you mean “if” the original metaupload site had copyrighted software? Have you ever visited it? It was loaded to the gills with illegal software, songs, movies, everything you could imagine. Is gigaom the only one on the planet that didn’t know that???? Wow. That’s what the site was for. That WAS the entire purpose of it. Did you think it made dotkom a multimillionaire just by having entirely LEGAL files on it???? Wow.

    • Come on, Jill. GigaOm (or actually, the author Andy Manoske) cannot say that the original metaupload site had copyrighted software, because that would expose the author to a legal liability for accusing someone of unlawful activity. That is why publications use the word “alleged,” or similar terms. Your comment is a little naive.

    • There were employees of the US government using Megaupload for file storage. You should tell them that their files were illegal. They probably have no idea. I had legitimate files on megaupload, but according to Jill I guess my files were illegal too. Too funny.

      Anyway, as for illegal files, simple Google searches will find that for you very easily and quickly. I wonder when the US govt will take Google down.

  8. This IS going to be more expensive for Mega because it will NOT be able to deduplicate common files. The same file encrypted by two different users using unique client-side encryption keys will be stored as two unique digital files.

    Mega will be in the clear because their terms of service clearly prohibit copyright infringement and they have no means of detecting if it is occurring.

    However, users should be aware that they aren’t as safe. If the FBI suspects that Mega is hosting a lot of illegal content, they will subpoena the content for analysis – and the FBI does have a lot of tools for cracking encryption. Buyer beware.

    • Mega will have “no means” of detecting illegal software???? Huh? The files will have to have SOME kind of description… and the enduser will have to see/get the decryption password. Why can’t the site also get it? Or the FBI? Just as easy.

    • Stjepan Zlodi

      Wrong! Read Mega TOS:

      Our service 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. In that case, you will access that original data.

    • Andy Manoske

      Thanks for the comment! A few comments have touched on this, but the novelty in Mega’s cryptography is in key management. Mega has worked particularly hard to design an architecture where users keep their own keys and leave the host with as little information as possible to recover the plaintext from the remotely-stored ciphertext.

      Many of the other approaches on the market employ cryptography where either the key is shared with the host (even if only for a short period of time), information that could be used to recover the key is shared with the host, or the key is generated in a way that could possibly be exploited in a partial information attack by someone with visibility into the host / the host itself.

      • John Tucker

        Clients keeping their own keys are nothing new. Many services did it long before MEGA. SpiderOak, Mozy, CrashPlan all offer private keys that stay with the user.