I imagine it's custom made. It looks like it even contains a bug. Not that it really matters for a hashing algorithm since in a sense you're just trying to output random garbage anyways.
It doesn't seem particularly secure cryptographically, but due to some irregularity, which strikes me as a bug, it's somewhat more difficult to analyse.
I've had a number of ideas to make it go faster. Some are implemented, some I think I started on, and then forgot about the project. I optimized the inner loop so it only replaces the last word (provided the length doesn't change), so it doesn't need to rewrite the whole string with sprintf. That was a huge speedup. (It also means you want the loaded words to be sorted according to length). Also, since the game only allows strings up to a certain size, it won't check through the whole dictionary if the size of the 3 substituted words exceeds the maximum string length. Hence, if you have long words at the start, it will run faster since it needs to try less words for the final position.
As for parallelizing it, just choose different values for k. Gpgarretboast said his computer could check a single value of k in about 68 seconds. (Dictionary size of a little less than 27000 words). It shouldn't be too hard to setup a different range for k for each computer it's run on. Now if only we had 27000 computers, we could check the whole dictionary in about 68 seconds.
(Actually, substantially less due to the string length speed optimization, since all the longer words are at the end of the dictionary).
Oh, and the planned but unimplemented part, was to hash the first part of the string, and save the results, and then continue the hash after the last word was changed. Then it wouldn't need to rehash the whole string each time. I think I added some code for that into the project, but it's not complete and not called anywhere. That should probably yield a speedup of about 2x or more.