Well that blew up, huh? If you follow emulation or just gaming on the whole, you've probably heard about the controversy around the Dolphin Steam release and the Wii Common Key. There's been a lot of conclusions made, and while we've wanted to defend ourselves, we thought it would be prudent to contact lawyers first to make sure that our understanding of the situation was legally sound. That took some time, which was frustrating to ourselves and to our users, but now we are educated and ready to give an informed response.
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.
Legality aside because I’m sure there’s always going to be some random law that they will use (or twist) to fight this… With 3DS I remember there was a community provided cloud cracking service. I’m guessing it was either some comically weak algorithm or they found some vulnerability they were able to exploit.
But even then that’s not really a good comparison because if there was some master key (I don’t know the specifics) it is still physically on your 3DS and they weren’t sending them around (or worse, hosting it on a store).
The situation sucks but I understand it from Valve’s point of view. It’s not about whether they think it is okay or not, it’s about them being concerned about liability from Nintendo who are well known for protecting their IP.
Get this: their digital licensing protection scheme was entirely client side. Which meant anybody with a hacked 3DS could just request any game they liked directly from the eShop.
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 of fixed size, the actual size being determined by the algorithm used.
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.
https://en.wikipedia.org/wiki/Hash_collision
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.
Legality aside because I’m sure there’s always going to be some random law that they will use (or twist) to fight this… With 3DS I remember there was a community provided cloud cracking service. I’m guessing it was either some comically weak algorithm or they found some vulnerability they were able to exploit.
But even then that’s not really a good comparison because if there was some master key (I don’t know the specifics) it is still physically on your 3DS and they weren’t sending them around (or worse, hosting it on a store).
The situation sucks but I understand it from Valve’s point of view. It’s not about whether they think it is okay or not, it’s about them being concerned about liability from Nintendo who are well known for protecting their IP.
Oh the shit on the 3DS was absolutely comical.
Get this: their digital licensing protection scheme was entirely client side. Which meant anybody with a hacked 3DS could just request any game they liked directly from the eShop.
A hash can take more inputs than it has outputs. By definition there have to be collisions.
…what are you even talking about? A hashing algorithm takes one data input and makes one hash from said data input.
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.
Your understanding is a little lacking.
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 of fixed size, the actual size being determined by the algorithm used.
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.