MEGA is genius(blog.setec.io)
blog.setec.io
MEGA is genius
https://blog.setec.io/articles/2015/10/18/mega.html
7 comments
not only is it possible, but Dotcom has alluded to exactly those things in his slashdot interview.
I don't see how this is genius.
Having hosts not know the contents they perform services for has been desired for a very long time. Research on homomorphic encryption predates mega by quite a while. And I am sure there must be backup services that already encrypted client-side long before mega.
The only reason why there wasn't something exactly like mega earlier was because browsers didn't have the capability. And it seems mostly like revenge for having megaupload shutdown. The profits aren't very good when you can't de-duplicate files (because the content is encrypted) or do anything else clever with the data. You just become a dumb provider of hard drive space and bandwidth. Anyone can clone client-side encryption.
Having hosts not know the contents they perform services for has been desired for a very long time. Research on homomorphic encryption predates mega by quite a while. And I am sure there must be backup services that already encrypted client-side long before mega.
The only reason why there wasn't something exactly like mega earlier was because browsers didn't have the capability. And it seems mostly like revenge for having megaupload shutdown. The profits aren't very good when you can't de-duplicate files (because the content is encrypted) or do anything else clever with the data. You just become a dumb provider of hard drive space and bandwidth. Anyone can clone client-side encryption.
Avoiding spam could be made less frustrating for users (report = frustration): require proof-of-work. The server presents some nonce and the client is expected to perform the old "hash until X zero bytes" POW and then add some extra entropy. This makes spamming computationally expensive.
In addition, because there may be multiple possible solutions for the problem, if the POW+entropy key is used with AES CTR, this could provide an additional layer of plausible deniability.
In addition, because there may be multiple possible solutions for the problem, if the POW+entropy key is used with AES CTR, this could provide an additional layer of plausible deniability.
It seems like given a public link including the decryption key, they could still be given a takedown request, since as soon as a rights holder sends them the link, they are no longer blind to the content. It does, however, preempt a Content ID like system.
It also makes it terribly un-fun wackamole for the rights holder.
If they had the files unencrypted, the rights holder could demand that every copy of file `foo` be removed. With this design, multiple uploads of the same file are not identifiably the same by MEGA, so that case can't happen.
It's interesting that they decided the benefit of encryption (lessened responsibility, marketing) outweighed the cost of wasted storage space for dedupe-able content.
If they had the files unencrypted, the rights holder could demand that every copy of file `foo` be removed. With this design, multiple uploads of the same file are not identifiably the same by MEGA, so that case can't happen.
It's interesting that they decided the benefit of encryption (lessened responsibility, marketing) outweighed the cost of wasted storage space for dedupe-able content.
Oh, certainly -- they still have to comply with takedowns, just as normal. But they don't have the ability to be forced to broadly remove content, and they have (arguably) plausible deniability about knowing that it's there.
They got caught, big time, last time over the fact that they were doing de-duplication on upload of content, and then when they received a DMCA for only one of the URLs, only taking /that/ one down -- even though they know it's actually also available in a bunch of other places.
They got caught, big time, last time over the fact that they were doing de-duplication on upload of content, and then when they received a DMCA for only one of the URLs, only taking /that/ one down -- even though they know it's actually also available in a bunch of other places.
Does manufactured plausible deniability provide as much protection? They could obtain all the keys used to decrypt files with a single logging statement, if they so chose.
Having no cleartext to hand over in individual cases is one form of plausable deniability. Cleverly, it also appears to offer plausable deniability of your service's "primary purpose", since there are few conclusions that can be drawn from the encrypted data in aggregate. So some protection, yes, but there are certainly other ways to get yourself indicted, or your customers blocked, under such general tests.
The example in the article shows the decryption key as a URL fragment, which never hits the wire. A subpoena on Mega's own servers is one thing, but a court compelling them to collect keys from client machines? I would hope not.
The example in the article shows the decryption key as a URL fragment, which never hits the wire. A subpoena on Mega's own servers is one thing, but a court compelling them to collect keys from client machines? I would hope not.
It feels likely they could claim that any court order to transmit and log the keys would be "unduly burdensome" and would in fact fly in the face of their carefully considered business practices.
We've seen court orders that caused Hushmail to create malformed Java apps which were then silenty delivered to target machines in order to break encryption.
http://www.wired.com/2007/11/hushmail-to-war/
People pretty much have no option but to comply with court orders. Most people are not going to go to jail so that other people can continue distributing stuff.
This should be a worry with Mega and its current owners.
http://www.wired.com/2007/11/hushmail-to-war/
People pretty much have no option but to comply with court orders. Most people are not going to go to jail so that other people can continue distributing stuff.
This should be a worry with Mega and its current owners.
They were talking about making offline & alternative OSS clients (via an open API) so that if they were legally forced to change the Javascript (which currently does the encryption) that it wouldn't affect the integrity of the service for those users.
No they can't
Notice the format of the URL
example.com/fileA#encryption-key
All MEGA has logged is: example.com/fileA
encryption-key
is generated client side and only sent to recipients, not the provider.
Notice the format of the URL
example.com/fileA#encryption-key
All MEGA has logged is: example.com/fileA
encryption-key
is generated client side and only sent to recipients, not the provider.
That's why I said one logging statement could grab the key. Just log the fragment to a service that you run somewhere, and all of the sudden you have the key.
who is "you"?
The fragment is only ever transmitted by the uploaded to the recipient. I'm not familiar with Mega but presumably this transmission is also encrypted.
So your chance of getting it is low.
And certainly Mega can deny ever receiving it.
The fragment is only ever transmitted by the uploaded to the recipient. I'm not familiar with Mega but presumably this transmission is also encrypted.
So your chance of getting it is low.
And certainly Mega can deny ever receiving it.
"You" being the people who wrote the client side script. Yes, the fragment is not normally transmitted to the server, but since the user is running code on their browser which was provided to them by mega, all mega needs to do is log the fragment back to their servers with a simple ajax call.
The point wasn't that mega can deny ever getting the key - the point was that this "security" system in place is very obviously designed to workaround the problem of mega knowing what files they were trading. This would probably be viewed as willful blindness and not actually protect them in court:
see: https://news.ycombinator.com/item?id=10415535
The point wasn't that mega can deny ever getting the key - the point was that this "security" system in place is very obviously designed to workaround the problem of mega knowing what files they were trading. This would probably be viewed as willful blindness and not actually protect them in court:
see: https://news.ycombinator.com/item?id=10415535
Not if the site used the service worker feature to pin secure versions of the site javascript on first connection.
Got a good guide for that?
From when I looked last, it's super experimental and not quite there yet.
This link[0] explained it reasonably well to me, though I'm still not sure on the security implications of pinning JS through it.
[0] https://github.com/slightlyoff/ServiceWorker/blob/master/exp...
This link[0] explained it reasonably well to me, though I'm still not sure on the security implications of pinning JS through it.
[0] https://github.com/slightlyoff/ServiceWorker/blob/master/exp...
Courts may not look kindly on such 'willful blindness':
https://en.m.wikipedia.org/wiki/Willful_blindness
https://en.m.wikipedia.org/wiki/Willful_blindness
This seems pretty relevant from your link:
> A famous example of such a defense being denied occurred in In re Aimster Copyright Litigation, 334 F.3d 643 (7th Cir. 2003), in which the defendants argued that the file-swapping technology was designed in such a way that they had no way of monitoring the content of swapped files. They suggested that their inability to monitor the activities of users meant that they could not be contributing to copyright infringement by the users. The court held that this was willful blindness on the defendant's part and would not constitute a defense to a claim of contributory infringement.
> A famous example of such a defense being denied occurred in In re Aimster Copyright Litigation, 334 F.3d 643 (7th Cir. 2003), in which the defendants argued that the file-swapping technology was designed in such a way that they had no way of monitoring the content of swapped files. They suggested that their inability to monitor the activities of users meant that they could not be contributing to copyright infringement by the users. The court held that this was willful blindness on the defendant's part and would not constitute a defense to a claim of contributory infringement.
They could easily grab the key with a little bit of JavaScript, however it would be detectable on the client side.
MEGA could have made byte-identical content de-dupable yet still unreadable to MEGA.. which would save storage space but might still retain the whack-a-mole quality: if your upload gets taken down, you may simply change any one byte in the file and re-upload. does MEGA do this? and if not, I wonder why not?
If the files are encrypted with different keys based on the URL, the files wouldn't be byte-identical.
Probably not. That's one of the things that had Megaupload jammed up. I think, in this case, disk space is cheaper than the lawyers' fees.
ah so they weren't even asked to ID content in a smarter way, like YouTube does? if their goal was really to enable piracy, did they think pirates would really give up without finding out that they could simply insert random bytes to evade takedown? Though I guess that would end up killing their de-duping rate anyway..
Note that MEGA is compromised: The NZ govt now owns a controlling portion of shares. Kim issued a statement saying not to use it, and to look out for an open source not for profit MEGA 3.0 when his non-compete expires late this year
http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-me...
http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-me...
"those shares were then seized by the New Zealand government -- Dotcom alleges"
Massive emphasis on alleges. If a person is thrown out of their own company, why would it be surprising if they then try to burn its reputation to the ground accordingly by claiming it's fully compromised. Not to mention Kim is planning a competing product, which casts further doubt on his credibility about the MEGA claim. His word is not good enough on this, more proof is necessary for such dramatic allegations.
And:
"In addition Hollywood has seized all the Megashares in the family trust that was setup for my children"
Uh what? Hollywood seized the shares? None of what he's claiming makes any sense.
Massive emphasis on alleges. If a person is thrown out of their own company, why would it be surprising if they then try to burn its reputation to the ground accordingly by claiming it's fully compromised. Not to mention Kim is planning a competing product, which casts further doubt on his credibility about the MEGA claim. His word is not good enough on this, more proof is necessary for such dramatic allegations.
And:
"In addition Hollywood has seized all the Megashares in the family trust that was setup for my children"
Uh what? Hollywood seized the shares? None of what he's claiming makes any sense.
Freenet has a similar model, in a p2p context. Anyone with a link can access the file, but the person hosting it plausibly isn't aware of its contents.
This is what services like 0bin.net and zerobin.net do for pastebin.
Edit: I should clarify. I mean a purposeful installed vulnerability at the point MEGA was build, not something that can be used after the fact.
[1](https://en.wikipedia.org/wiki/Dual_EC_DRBG) [2](https://en.wikipedia.org/wiki/Random_number_generator_attack)