Forgot your password?
typodupeerror
Encryption Privacy

Software Developer Says Mega Master Keys Are Retrievable 136

Posted by timothy
from the any-mega-users-out-there-who-care-to-try? dept.
hypnosec writes that software developer Michael Koziarski has released a bookmarklet "which he claims has the ability to reveal Mega users' master key. Koziarski went on to claim that Mega has the ability to grab its users' keys and use them to access their files. Dubbed MegaPWN, the tool not only reveals a user's master key, but also gives away a user's RSA private key exponent. 'MEGApwn is a bookmarklet that runs in your web browser and displays your supposedly secret MEGA master key, showing that it is not actually encrypted and can be retrieved by MEGA or anyone else with access to your computer without you knowing,' reads an explanation about the bookmarklet on its official page."
This discussion has been archived. No new comments can be posted.

Software Developer Says Mega Master Keys Are Retrievable

Comments Filter:
  • by Anonymous Coward on Tuesday September 03, 2013 @01:34PM (#44748165)
    I don't think there are many people who would trust Mega anyway. I mean, we all pretty much feel the US (and the New Zealand) governments overreached and broke laws when they begin prosecuting Kim DotCom, but most people realize that the guy is a self-aggrandizing scam artist and charlatan. Does anyone actually trust his stuff?
    • Re: (Score:2, Interesting)

      but most people realize that the guy is a self-aggrandizing scam artist and charlatan

      This. The man is just the flip side of the copyright cartel, and they're both about the same thing: getting rich by leeching off the hard work and creativity of others.

      Cue a hundred Defenders of the Faith claiming that this is well-engineered incompetence, not malice, and that a hole as wide as Uranus is actually not serious.

      • ...and that a hole as wide as Uranus is actually not serious.

        Mine, I wouldn't worry about. Your mom's on other hand...

      • by Anonymous Coward

        This. The man is just the flip side of the copyright cartel, and they're both about the same thing: getting rich by leeching off the hard work and creativity of others.

        I've said it before and I'll say it again. Mega is simply an Internet file hosting service. It is not Kim's fault that people use Mega to commit copyright infringement. Kim's Mega business is as legitimate as any other Internet business such as Napster, Grooveshark or eMule.

    • by denmarkw00t (892627) on Tuesday September 03, 2013 @01:51PM (#44748389) Homepage Journal

      Does anyone actually trust his stuff?

      For sensitive material? Of course not. But, I have used Mega a number of times for legit downloads (Android ROMs, Linux, various open-source projects). Let's not forget that MegaUpload was used for non-nefarious purposes, although people who store sensitive data unencrypted on someone else's service are always taking a risk.

    • by sosume (680416)

      At least he's not lying about himself or his intentions. If anything, he's been absurdly honest. Just look at his licence plates, or one of his bragging pictures.

    • by aaaaaaargh! (1150173) on Tuesday September 03, 2013 @02:19PM (#44748727)

      the guy is a self-aggrandizing scam artist and charlatan

      However, if he wore a suit with tie and had not only fullfilled DMCA requests (which he always did) but also had proactively given away his customers data to any US authority and private copyright holders like the RIAA without any real legal basis and had additionally given money to the two leading US parties, he'd be considered quite a decent fellow in the US now. In other words, while he never did anything else than Google and thousands of other companies, including US ones today, he hasn't shown "the right attitude" and that is the main and real reason why he is being persecuted now. He doesn't act the way you are expected to act as a rich entrepreneur with a serious business. Such misbehavior is usually sanctioned. They even wondered whether they could turn an inflatable tank he had in his garden into some kind of evil plot, but didn't manage to find the right legal angle to it...

      Regarding trust ... well, at least New Zealand law cannot force you to install backdoors and lie to everyone about it, but of course you cannot trust any closed source company with data security. Encrypt on your own before storing something on Mega and you're fine.

      • by wagnerrp (1305589)
        All those other companies gave no illusion of being secure. Hell, they often had in their own terms and services that they would be reading your email for whatever purposes they desired. Kim Dotcom claims to be offering secure, encrypted services, yet anyone with a basic understanding of computer security can tell he's just putting up a facade for the masses. That's why he cannot be trusted. He's nothing but a blowhard.
        • by Barefoot Monkey (1657313) on Tuesday September 03, 2013 @04:05PM (#44750121)

          All those other companies gave no illusion of being secure.

          Neither did Mega. They explain these very risks and others right in the FAQ [mega.co.nz] and since they launched have using alternatives that do not involve trusting them. Providing a interface is a significant convenience, but you can't trust anything truly secret to a script someone else can remotely replace on a whim.

          • by Barefoot Monkey (1657313) on Tuesday September 03, 2013 @04:13PM (#44750239)

            Proof-reading fail. Sorry :(

            The missing word was "recommended". They have always recommended alternatives that do not involve trusting them. Here's an example from that same FAQ page:

            What if I don't trust you? Is it still safe for me to use MEGA?

            If you don't trust us, you cannot run any code provided by us, which precludes opening MEGA in your browser and entering your login credentials. However, due to MEGA's end-to-end encryption paradigm, you can safely use client applications written by someone you trust.

      • by Tom (822) on Tuesday September 03, 2013 @03:34PM (#44749721) Homepage Journal

        he hasn't shown "the right attitude" and that is the main and real reason why he is being persecuted now.

        If you aren't a paid shill, you should change that. Your misleading and faulty argument surely qualifies, and you'd have to be an idiot to think that a multi-millionaire scam artist in the public spotlight would not have hired a PR agency to improve his online image.

        Kimble is a career criminal, simple as that. He was prosecuted and even convicted before, and by several other governments. That distinct sound you're hearing is the shattered pieces of your argument falling apart.

        If you are a large-scale career criminal, there are two paths you can go.

        One, you can fly under the radar, like the people in the famous train robberies and serial bank breaks that many of us have heard about but almost nobody can name even one of the actual people involved.

        Two, you can scale it up so much that it becomes quasi-legal by sheer scale and being-part-of-the-system, like the financial industry, the corporate corruption or the various pet-sectors of the various countries that are untouchable (Spain had a huge real estate scandal - nobody was ever convicted. Germany even has a name for the network of corporations, banks and government entities so closely connected that they all protect each other: Deutschland AG. In Greece, the shipping industry was holy for decades. In the US it is probably the military industry, and so on).

        Kimble was arrogant and self-obsessed enough to think he could reach the same place simply by having an overblown ego and being audacious.

        • by danaris (525051)

          In the US it is probably the military industry, and so on

          Nah, over here it's the financial services industry.

          Y'know, the ones who just recently broke the whole system for everyone in the western world, and then got the government to pay them to make sure they didn't stop doing the same things that led to the crisis.

          Dan Aris

      • by Anonymous Coward

        Regarding trust ... well, at least New Zealand law cannot force you to install backdoors and lie to everyone about it,

        That might have been true earlier, but I think the recently passed GCSB and TICS bills now allow it. JohnKey wanted to bring NZ laws into alignment with the US and UK... But he says you can trust him, he'll only use the powers against bad people, and anyone who disagrees (like the law council and human rights commission) just doesn't understand the new laws.

    • by glassware (195317) on Tuesday September 03, 2013 @02:54PM (#44749225) Homepage Journal

      I read this as "Sega Master System Keys Are Retrievable." I was sadly disappointed.

    • by Tom (822)

      Does anyone actually trust his stuff?

      Idiots with no knowledge of history.

      Kimble ratted his partners out to the FBI when he was under investigation for a previous crime some years ago. Once a traitor, always a traitor. If you think there are no closed-doors talks between Kimble who's trying to save his neck and the government, you must be very naive indeed. And the obvious thing that Kimble can offer is - the users of Mega, of course.

    • Not me. I wouldn't host anything I didn't care about on any server he had any control over, let alone something important. The guy is a crook, pure and simple.

    • by Inda (580031)
      I trust Mega. I trust them to store some files and serve them to anyone I provide a link to.

      Forgetting that sometimes the uploads stick on 99%, and forgetting that some files timeout at random times and restart the upload from 0%, it's a really nice place to store 46gb. The up/down speeds can't be grumbled at either.

      I couldn't give a flying shit if they are encrypted, nor do I care if they are ever deleted. I have local copies.

      What am I suppoosed to be trusting again?

      Kim DotCom gives me a large amount of fr
  • by Noishe (829350) on Tuesday September 03, 2013 @01:37PM (#44748209)

    Once you enter your password into a website, the website can do anything that you can do.... Duh

    Yes, mega doesn't have your key stored on their servers.
    Yes, at any point while you're logged in they can change this fact, or they can just log your password, or whatever.

    Doesn't matter what the website is, you have to trust it to use it.

    How is this news?

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      not to troll but this may be a new tactic by Big Media or maybe the NSA to try and cripple Mega and others, I find it odd, (tho I do not make an conspiracy out of it) that the NSA is attacking owners of sites that refuse to give up there encryption, and the owners/creators are shutting there sites down.

      It is possible and wouldn't be surprised to see someone or some sinister force at work here. But I am not sure if the creator of the exploit is supporting Mega, and trying to improve its security or trying to

  • by schneidafunk (795759) on Tuesday September 03, 2013 @01:37PM (#44748213)
    I don't get it, why is this a big deal? This just displays your local storage in your web browser.
    • by Anonymous Coward

      i fixed this problem on my project using javascript closures. your private keys are decrypted with your password. password is never uploaded to the server. you can see that by looking at the post requests. the decrypted key is stored in a local variable for activities the rest of your session. closures are secure. no program outside the function scope can access the keys or password. its tricky to get right so maybe Mega can fix it soon.

      • by Anonymous Coward

        Still everyone has to trust the site to not deploy malicious javascript. That's why this concept is fucked up ...

      • by vux984 (928602)

        i fixed this problem on my project using javascript closures.

        How does that fix anything? Every time I visit your project, I must rely on your java script. The fact that it is correct today does nothing for me tomorrow.

        A secure solution requires that there is nothing you can do to get my key.

        You could simply change the java script on your site tomorrow, and slurp the key next time I visit.

        Essentially one has to decouple the client from the service, so that I use a client YOU DON'T CONTROL. That is the only

      • by psydeshow (154300)

        A real fix to this problem would let me download the js and html and whatnot once, as a signed archive, and use your application from a file:// url on my computer.

        In other words, the only thing that would come from a server from session to session is the encrypted data file. No application code. No HTML. Just the data.

        It's a lot more like a traditional application, except that it runs in the browser and the source code is right there for me to look at.

    • Yeah, I saw this tool was already built in to Chrome, so I guess I've had the hack for a while - even before this guy released it!

  • by YesIAmAScript (886271) on Tuesday September 03, 2013 @01:38PM (#44748223)

    That's how you want it to be. It's zero-knowledge from MEGA's point of view. You generate your own key, keep it and use it to decrypt and encrypt stuff.

    So of course if someone gets access to your computer they can get your key, it was on your computer all the time, by design.

    His assertion that MEGA can get your key is what is a bit more surprising. But if you read it, he's simply saying it's conceptually possible that MEGA could use a script on their site to grab your key and send it to them. This is of course possible, but we have no way to know whether they've done it. If the javascript can access your key to encrypt/decrypt stuff, then it is also possible it can squirrel it away somewhere.

    • His assertion that MEGA can get your key is what is a bit more surprising. But if you read it, he's simply saying it's conceptually possible that MEGA could use a script on their site to grab your key and send it to them.

      And you think this isn't serious? Every vulnerability is "conceptually possible" until it's implemented. NSA/FBI/local bobby want to see what you've been using Mega for? Slip in a one time bit of Javascript to a page delivered by Mega, and it's all theirs for the reading.

      Perhaps you don't even understand what Mega has been promising up to now.

      • by amicusNYCL (1538833) on Tuesday September 03, 2013 @01:59PM (#44748485)

        As far as I can tell there isn't any other way to do it. If Javascript needs access to that encryption key then of course it is possible to send that key anywhere else. It sounds like there is some client-side encryption that takes place before sending files, and that encryption code presumably comes from Mega, and that encryption code uses your private key, so of course the encryption code has access to the key. How could it encrypt otherwise? The browser doesn't natively support that process, that is what would have to change in order for this to not be an issue. The promise by Mega not to store your keys is the only thing that users have, because if they are running Mega's encryption code client-side then there is nothing stopping Mega from getting your keys, or unencrypted data, or whatever else, other than their promise not to.

        NSA/FBI/local bobby want to see what you've been using Mega for? Slip in a one time bit of Javascript to a page delivered by Mega, and it's all theirs for the reading.

        Again, the onus is on Mega to stop that from happening, but they can only protect their own servers. If someone wants to intercept and decrypt your traffic and change the data to add new code (a man-in-the-middle attack), then that is still a threat. It's always going to be a threat as long as organizations like the NSA are capable of decrypting that SSL traffic.

        Otherwise, this is not an issue that has a solution with today's browser implementations. Maybe Mega can produce their own version of Firefox or a Webkit-based browser that will natively implement their encryption without exposing the keys to Javascript, but then you would have to trust that software, don't you? It's all about trust. If you don't trust Mega, then don't use it.

        • By using a proper browser plugin rather than a crappy Javascript implementation, perhaps?

          Yes, it is all about trust: companies ask you to trust them, then their reputation is built or broken. Evidence for either is welcome.

          • I'd agree that this is not really a vulnerability in the traditional sense.... but under the circumstances, Mega should (IMO) do more to convince customers the data they store there isn't going to be viewed by any 3rd. parties.

            Ultimately, I suppose a custom browser plug-in could be written which would divulge your secret personal key, too. But I'd rather see a less trivial process to upload a user's key than some basic javascript making it possible. (Otherwise, it's too easy to trick a user into visiting

        • The promise by Mega not to store your keys is the only thing that users have, because if they are running Mega's encryption code client-side then there is nothing stopping Mega from getting your keys, or unencrypted data, or whatever else, other than their promise not to.

          It is likely that this was an intentional design flaw, introduced at the behest of one or more government agencies (I didn't say which government, and you shouldn't assume!). You'd be surprised what threats of torture, destitution, or prison, can do -- especially to someone like kim dot com, who is used to a higher standard of living. You can't really threaten a poor person; Government long ago learned to forget that strategy and instead go after their family and/or lover. But a rich person? oooh, so very m

          • by Anonymous Coward

            Except who owns the TPM MASTER KEY?

            TPM is not and never will be a secure method of key storage. It's just another form of Key Escrow.

            • by heypete (60671)

              That's irrelevant in this particular situation: the TPM is merely being to securely store a key and use that key -- entirely within the TPM -- to encrypt or decrypt data. The TPM could (and likely does) store other keys that aren't being used for this particular task, but that doesn't matter in this scenario. Although TPMs can be used for various purposes, in this case it'd be used like cryptographic smartcard or HSM.

              Are you aware of any way of retrieving a private key stored on a TPM by any means other tha

        • by swillden (191260) <shawn-ds@willden.org> on Tuesday September 03, 2013 @02:38PM (#44748969) Homepage Journal

          As far as I can tell there isn't any other way to do it. If Javascript needs access to that encryption key then of course it is possible to send that key anywhere else.

          At present, this is true. There's a W3C WebCrypto spec in progress (being developed by Google and Mozilla, IIRC) that will change it, though. It will not only provide native implementations of ciphers accessible from Javascript (rather than performing expensive calculations in Javascript), but will also provide a client-side key store so Javascript code can create and use keys without ever seeing their value, and hence be unable to send the values anywhere.

          I think the Javascript code would still have access to the decrypted data.

          Caveat: It's been a while since I looked at the in-progress spec. It may have changed, and I guarantee my memory is faulty in at least some respect.

          • by BitZtream (692029)

            There's a W3C WebCrypto spec in progress (being developed by Google and Mozilla, IIRC

            So its being implemented by the two vendors who slip in silent updates faster than my sister spreads her herpes? This really isn't any better when they can just silently send you an update to relay your keys off to them. You've been trained to accept their updates without thinking about it, good job, same problem.

            • by flux (5274)

              Just like your OS vendor can slip in an update that sends all your keys to them. (As Shuttleworth said, they have root.) You basically need to trust someone, as no one person is able to audit everything people typically use daily.

      • by bluefoxlucid (723572) on Tuesday September 03, 2013 @02:03PM (#44748523) Journal

        The issue is that it's 'conceptually possible' for Ubuntu to ship a package in the base system that uploads your keys to Canonical's servers. I can give you a script that you run on RHEL and it'll show decrypted ssh, ssl, and gpg keys (if you've entered the password). I can put a package on your system and show that RHAT could put a modified gpg that logs all your shit and passwords and everything to their server. And so on.

        This isn't a vulnerability. It's like saying it's conceptually possible for a thief to steal your car after you've put the key in the ignition.

      • It's not a question as to whether it's serious. It was always the case and could be assumed to be the case. If the JavaScript can get to your key to use it to encrypt/decrypt, it can also possibly upload. It's part-and-parcel of the design.

        I pointed this out when MEGA was first announced. There always is the possibility of a system squirreling away your keys. You cannot design it out in software. The software reconstructs your key at some point, you then have to trust it discards after using it only for the

    • by OverlordQ (264228)

      So of course if someone gets access to your computer they can get your key, it was on your computer all the time, by design.

      Or at any time Mega can sneak in a bit of extra javascript to send them your key too. How many people actually audit the javascript every time they visit the page. It's the main reason why client-side encryption is bullshit. It just adds extra vectors of attack, rather than makes things more secure.

      • by DarkOx (621550)

        When the method is javascript in the browser; sourced from the very same service you are sending the encrypted data off to than yes; client side encryption is BS and probably offers so much attack surface it reduces security.

        The fundamental problem here is you are running 'untrusted code' to handle sensitive information. There is a solution here. A small simple OSS program easily audited. Probably needs to be real real basic command line utility using few if any external libraries so people can post the

        • by OverlordQ (264228)

          Yes, or an actual browser plugin/extension which will let you do proper sandboxing and code signing.

        • by psydeshow (154300)

          Or the code comes from a known-good set of files on your local drive, and only the encrypted data is transferred to and from the cloud.

          HTML + CSS + JavaScript files == open source. As long as you load them using a file:// URL you can know what exactly you're getting.

          This is preferable to an extension which is a) compiled and b) could access every page my browser visits.

          • by DarkOx (621550)

            I respectfully disagree. This almost needs to be a pure C implementation and like I said use few or no external libraries. Java script and HTML renders are big beasts. You can't possibly audit them as an end user. Yea the C compiler is to big and complex for most people to practically audit as well; hence what I said about posting md5sums, so you have some verification if imperfect that your compiler is producing output that really corresponds to the input code you just audited.

    • by sjames (1099)

      I it can display it to you, it can post it to the server.

  • Summary (Score:5, Insightful)

    by LordLimecat (1103839) on Tuesday September 03, 2013 @01:39PM (#44748233)

    Unless Im misreading it, this can be summarized as follows:
      * Coder has discovered that, in order to encrypt data, your computer must have access to the encryption key
      * Further, if someone has root access to your machine, they can get your encryption key.

    Wow. What a discovery.

    MEGA and anyone else with access to your computer can see this, and use it to decrypt any file you upload.

    Wait, someone with access to my computer has access to things that my computer has access to? WOW!

    • Only if you define "someone with access to my computer" to include "anyone who runs a web server I visit".

      • Pretty sure such an attack would qualify as a cross-site scripting vulnerability.

      • Only if you define "someone with access to my computer" to include "anyone who runs a web server I visit".

        The article doesn't say that any web site can access the key, just the browser itself (via bookmarklets or third-party extensions) and Mega. Both of which are obvious.

        The browser prevents sites from accessing other sites' local data. It would be interesting if they managed to find a way around that protection, but they didn't. The system is working as designed.

        • Eh, you could easily write a plugin which doesn't allow any Javascript to access its private data. It might involve platform+browser-specific implementations, but doing things right isn't always easy.

          • I don't disagree. My own preference would be an open-source native client with no ties to the browser, something stable which can be audited and won't be replaced every time Mega updates their web site. However, the existing system isn't exactly handing the key out to every web site you visit, just the components which are expected to have access to it. It's about as secure as can be expected of a plain web app.

      • by Arker (91948)

        "Only if you define "someone with access to my computer" to include "anyone who runs a web server I visit"."

        That definition works, if you are foolish enough to enable javascript.

        • And foolish enough to run a browser which doesnt prevent cross-site scripting attacks.

          Hey, if your browser allows random websites to pull all of your cookies, your login sessions could be compromised! Except, they do restrict that.

          • by Arker (91948)
            I dont allow cross-site scripting without whitelisting myself, but it's important to realize this is a compromise that reduces vulnerabilities but does not eliminate them. In this case, it's NOT cross-site scripting we are worried about.
        • by wagnerrp (1305589)
          The Mega site runs javascript. If you do not enable javascript, you cannot use Mega. Of course in that scenario, this whole discussion is moot.
          • by Arker (91948)

            "If you do not enable javascript, you cannot use Mega."

            And that is indeed my point. If it wont work when you turn javascript off, it isnt a webpage, and it definitely cannot be trusted.

    • by Laxori666 (748529)
      Well. The whole point of Mega was that not even Mega would know what you are storing on their servers. "The end to end encryption means that Mega pretty much can't narc on you, no matter how much pressure it's under. It won't know what you're storing on its servers, by design." gizmodo [gizmodo.com]. Thus there's a reasonable expectation that Mega cannot find out what you are storing on its servers. Now it turns out there is a ridiculously easy way for Mega to find out what you're storing there: all Mega has to do is run
      • Indeed. If you want to store encrypted files, then encrypt them locally before uploading them.

        • That is what is happening here. Just from reading the article, I can see that the key is using local browser storage, which is used to encrypt the data and upload to Mega. Mega is NOT doing the encryption (thats the entire point of doing it in JavaScript).

          • by Hatta (162192)

            Just from reading the article, I can see that the key is using local browser storage

            Which is about as secure as storing the key in /var/www.

          • What I'm saying is that if you don't want your files to be seen, then you encrypt them outside of the browser before uploading them. If you're encrypting them in the browser then that's a vulnerability. The browser can encrypt the already-encrypted file if it wants to, if anyone decrypts it they're just going to get another encrypted file back.

          • If you want to store encrypted files, then [you must] encrypt them locally before uploading them.

            Emphasis and clarification added. The problem isn't that the files aren't getting encrypted before upload, it's that *you* aren't doing it. Your browser, executing JS code from mega.co.nz, is doing it. You aren't even running the encryption program yourself; it's all automatic. You are handing Mega an un-encrypted file, and trusting them to securely encrypt it against themselves. Does this sound stupid yet? Let

      • Yes, basically there's no way this security model works. Their promise is that they give you client side software (java script), the software does all the magic on your end, then gives them impenetrable black boxes. That's it.

        Microsoft EFS promises that Windows doesn't upload your encryption keys to microsoft.com. Apple's encryption tools, same. PGP and GPG, same. We really really promise we don't send your private keys to home base, then add back doors to your computer and come snooping your filez.

  • Two back-to-back /. articles with the superlative "Mega" in the title. The next scientific discovery will need to be ÃoeberMega to reach the front page of /.
  • The problem with storing data in the cloud with encryption from the providers standpoint is that you can't use dedupe on it. Dedupe can make an extremely large difference in the amount of storage that you have to buy and run. From an operational costs standpoint the difference between running a data repository with and without dedupe could easily be the difference between running at a profit or a loss.

    The service provider has a very strong financial incentive to use dedupe technology. The problem is that th

    • by flux (5274)

      There is a way to do dedup without having the key.

      For example: the client takes an SHA256 of the data, then encrypts the data it with the lowest 128 bits of the SHA1, uploads the encrypted data to the server saying "this data has id ". The lowest 128 bits are then encrypted with the client key and uploaded as well. This way another party with the possession of the same data gets the server to merge their data (but the key still keeps hidden from the server). Servers makes an SHA1 sum of the encrypted data s

  • by Anonymous Coward

    I worked for a company that wanted to offer secure cloud backup. A crucial requirement was that the company would never have the encryption key, and we went to significant lengths to do that. But the users wanted a way to download their files from the web. Well, how were we supposed to send the user a decrypted file if we didn't have the decryption key? Solution: The user must enter the key into the web app, then the server decrypts the file and sends it to them. So now, in theory, the company could si

  • by TheSpoom (715771) <[ten.00mrebu] [ta] [todhsals]> on Tuesday September 03, 2013 @01:54PM (#44748435) Homepage Journal

    So this is obvious to anyone with knowledge of encryption. I believe Mega's claim is that because the encryption is done on the client side, they don't know the key. This could be true, but you still have to take their word for it.

    But even though it's obvious, it's something to consider. Mega claims that they could not decrypt your files. This is demonstrably false. So what's to stop the government from serving them with a National Security Letter that forces them to add code to the login process, logging all keys upon login, without any advance warning to their customers?

    There's essentially no way to trust a third party on the internet now without an alternate, reliable channel of communication to exchange keys in the first place.

    • by PRMan (959735)

      So what's to stop the government from serving them with a National Security Letter

      He's not in the USA and never has been?

    • by Terrasque (796014)

      > Mega claims that they could not decrypt your files. This is demonstrably false.

      Not quite.. It requires all these things to happen:

      1. Mega gets a reason to get your key (LEA for example)
      2. Mega adds new JS just for you
      3. You use the web interface
      4. You log in
      5. You don't notice the new code (Mega already have a chrome browser extension that would stop this by running its own code instead of the server's code iirc)

      So.. They have to start looking for your key, you have to use the *web interface*, AFTER th

  • my luggage number is 742. One less thing to worry about.
  • ...thanks for the huge back door up my ass, Kim.
  • by ArcadeMan (2766669) on Tuesday September 03, 2013 @02:56PM (#44749247)

    I read the title as "Software developer says Sega Master keys are retrievable".

    • I was really excited to read something about the Sega Master System and was bummed out when I realized my mistake.
  • All the files I store on the Cloud are encrypted locally on my machine by GPG before being uploaded to Google Drive, Mega or whatever. Now it is possible that a backdoor/exploit of my OS's code or GPG's code or hardware could leak my keys, but that's significantly more difficult to accomplish than simply changing a few lines of JavaScript the next time my browser pulls down the uploader's page.
  • The first time I read the headline it said "Software Developer says MegaMan Master keys are Retrievable" so I thought it in regards to was some kind of ROM DRM. Second time I read it, it said "Software Developer says Sega Mega Keys are retrievable". So I googled Sega Mega only find that the Sega Genesis (or some variation) was marketed with that name in some parts of the world. This made some sense, although didn't really seem to belong in YRO. Is my mind deteriorating faster than I expected or is the Illum

  • We knew this was an issue from when Mega was first launched. All this guy has done is made a pretty useless bookmarklet. Obviously if there is code on your computer that has access to the key and can be changed remotely then whoever can change the code can steal the key. Luckily Mega provides an API so this is a non-issue provided you use a client on your local computer.
  • Soooo, in essence, the guy managed to verify WHERE in the browser Mega stores is Master Key?

New systems generate new problems.

Working...