@nekusoul I want to add that the mentioned Wii keys was always controversial. Dolphin core is part of RetroArch and the RetroArch team never included those keys, because they knew someday it would only mean trouble. That is why Dolphin is still in RetroArch available on Steam. That's why the installation of Dolphin core on RetroArch is a bit more involved, because they do it the safe way. Glad this project will continue to exist.
In the article they actually state they believe it is actually better to have the keys included and not rely on some method of inserting them.
After this situation blew up, we received many requests, and even some demands, to remove all Wii keys from our codebase. We’re disappointed that so many people on YouTube and social media didn’t even consider that maybe the team had done their research and risk analysis before including the keys, and just assumed that now that it was “pointed out to us” we would remove them. However, we do not think that including the Wii Common Key actually matters - the law could easily be interpreted to say that circumventing a Wii disc’s encryption by any means is a violation. As such, it is our interpetation that removing the Wii keys would not change whether the exemption in 17 U.S.C. § 1201(f) applies to us or not.
In fact, we think that offloading decryption tasks onto a potential 3rd party application would make the situation worse for everyone. As such, we believe leaving the keys as they are is the best course of action.
@Creesch Not everyone agrees with this approach. That's why it is controversial. But fact is, it is a risk to include the keys for anyone hosting the emulator, until it's crisp and clear decided by court or by Nintendo. Until then we (the community), or the dev team, nor any lawyer knows with certainty if this is allowed or not. And that is the problem; we don't know.
Fyi, you don’t need to ping someone when replying to them ;)
Anyway, yeah I get that it is controversial or already was. But you said it in isolation while the blog post explicitly goes into that choice which I think is important for context.
I know, but I add the id (its automated anyway) because it makes it a bit easier to follow discussion if others reply too. In example the upvotes will change the order (in my view at least) and I would need to scroll up and down to see who the answer was to. Doesn't matter too much, but if it does not hurt, then I would continue like this. Or does it somehow spam the notification? Then I would reconsider this approach, as my goal is not to annoy anyone.
As for the legal stuff; there is not much else to say for us about the situation.
I don’t know why a few of these emulators require stuff from real hardware in the first place. Bleem didn’t and wasn’t passing around copyrighted material, yet every other PS1 and PS2 emulators I know of require .BIN files dumped from a real unit. This is the main thing behind Dolphin being taken off Steam; they’re distributing a thing that is violating a copyright. Surely there is a way around this Wii key bullshit the same way Bleem was able to operate without an actual playstation BIOS, right?
@Kolanaki BIOS is software that can be rebuild. It's always better to use the original firmware and BIOS for maximum compatibility. The Wii keys on the other hand are not software you can rebuild. These are key codes to unlock a protection, something like a serial key. So the situation is much different from the Bleem thing.
Would another key work? My guess is no because we’re dealing with encryption and not hashing. With hashing you can theoretically find multiple inputs that make the same output. Also I have no idea how many bits the key is. It can easily go from a “get a community driven distributed computing event to crack it” to “have you heard the one about monkeys and Shakespeare?”
That is what we call an attack, or a vulnerability. It isn't supposed to happen, and at the point where it does, that algorithm becomes cryptographically insecure and should not be used.
I see what you're thinking though, as it would be such an old hash that collisions must be known, right?
Well unfortunately, what we are dealing with here is encryption, not hashing, and hash collisions do not apply as an attack vector to encryption.
You could in theory try a cryptographic attack on the encrypted data but then you run into a few other problems:
you're effectively distributing a DRM bypass tool, expressly forbidden under DMCA
Attacking even the likes of RC4 takes considerable compute time on modern systems
If you do crack it, you legally can't store it, which compounds problem number 2.
A hash converts a large input into a small output. If a hash takes up to 128 ASCII characters and outputs 64, there will be ~10^135 collisions per output. This is completely normal and not a design flaw. It's simple math.
The strength of a cyyptographic hash function (not the only kind of hash or the only useful kind) is in not being predictable, not in avoiding collisions.
Hash algorithms don't take an input and make it smaller. What they do is, they take an input, plug it into a mathematical formula and that outputs a string of text.
There are a few key factors people take into account while making a hashing algorithm:
collision resistance. It won't ever be possible to make it completely resistant, so they aim to make it unfeasible to do with the foreseeable future of technology. Many technologies we rely on, such as TLS, rely on hashes for verification purposes, so collision resistance is very important for that.
irreversibility. This is a big reason why it doesn't simply convert big output into small output (the other being that hashes can actually be bigger than the input data itself). Information is lost in the hashing process to the point where you can't take a hash and unhash it into the original data.
reliability. The algorithm must create the same output given the exact same data.
predictability, like you said, but only kinda. While it is true that a requirement is that an attacker must not be able to derive even part of the original data, a lot of the onus here is actually on the user to not use predictable inputs when using hashes for secure things. As said before, a hashing algorithm must give the same output when given the same input, so someone using, let's say a hashed timestamp for something secure is being a moron.
They have a fixed size output, yes. That output is effectively universally substantially smaller than the input it supports. The fact that they can also take smaller inputs as well increases the actual number of inputs, because those are in addition to the number of full length messages. The point is that the input space is a fuckton of orders of magnitude larger than the output space, which means you're literally unconditionally guaranteed that collisions have to exist.
Half your points are specific to a cryptographic hash, which isn't the only kind of hash or the only useful kind of hash, but since that's what you're talking about fine.
Collisions existing are normal. You can only avoid making finding a collision easier than finding the actual input for a password application and finding a collision with a modified hard to do for a checksum. The collisions still exist. In some applications of hashing, eg semantic hashing, collisions for similar inputs are desirable.
Yes, this is the point of a hash, but it's not hard to do.
Again, same thing. Deterministic code isn't that hard to do.
Preventing predictability is the only point for a cryptographic hash (besides being deliberately heavy to prevent brute force). If there aren't systematic flaws to make the distribution of outputs distinguishable from randomness, your cryptographic hash is going its job.
Did you even read the post? They say that they believe that including the decryption key is not violating anything as its only a small portion of the software.
It was taken off Steam because Valve asked Nintendo how they felt about it - Nintendo obviously didn’t like it, so Valve said Dolphin needs to be removed unless they can get permission from Nintendo.
we do not think that including the Wii Common Key actually matters - the law could easily be interpreted to say that circumventing a Wii disc’s encryption by any means is a violation
Their conclusion is that it doesn’t matter because it might or might not be ok either way.
Dolphin is an independently created computer program that is circumventing Wii disc encryption for interoperability with Wii software. According to this exemption, this does not constitute infringement under 17 U.S.C. § 1201. This exemption even allows distribution of information collected through circumvention, like encryption keys, if it is for software interoperability.
17 U.S.C. § 1201(f) is a significant legal protection for emulation in the US, and it is why Nintendo has yet to legally challenge any emulator with the DMCA anti-circumvention clauses despite the law going into effect 25 years ago. Unless a court rules that our understanding of the law is incorrect, we have every reason to believe that our decryption of Wii game discs is covered by this exemption.
Their conclusion is that they believe that they fit in the exemption clauses of the DMCA and therefore, they are not breaking the DMCA by including a mechanism or the key. They think that the exemption clause might not apply if the key or decryption mechanism was standalone.
Yup. Although it seems like Nintendo is believing it as well, considering they didn’t already shut the project down years ago. Either that or Nintendo just doesn’t want to risk a second Bleem ruling, legalizing emulation even further.
You can operate without a BIOS if you implement a compatible one from scratch. That’s how IBM PC clones came to exist.
But an encryption key has to be exactly the same as the original, and although I doubt it can be copyrighted, it is definitely a technological protection measure per DMCA.
Add comment