4 ms·

You'd need to run many parallel processes like MD5(MD5(MD5(thing1))), MD5(MD5(MD5(thing2)))... I think the math still works if you do that. But the cycle would

You'd need to run many parallel processes like MD5(MD5(MD5(thing1))), MD5(MD5(MD5(thing2)))... I think the math still works if you do that. But the cycle would have to be contained entirely within one of the individual runs. So that could potentially take longer. The tricky part would be combing through the 160 exabytes of output to find the cycle.

fsckboy 4y ago
> The tricky part would be combing through the 160 exabytes of output to find the cycle I don't think you get to leave that out of the O(?) of this problem
- Retr0id 4y ago
  You can, since there are cycle detection algorithms that do not increase the big-O complexity at all (constant factor).
hinkley 4y ago
So I’m getting much bigger than 160 exabytes. Can you show your math? MD5 is 128 bits so that’s 2^128 keys. And it’s 32 bytes for the output, so that’s really 2^133 bytes. Which is 10^38 which we don’t even have a unit for yet. Apparently it’s 100 million queccabytes. You can get that down to two million queccabytes if you use a Bloom filter.
- manimino 4y ago
  You don't have to generate every possible md5. Just ~10^19 keys is enough to probably have a cycle.