# RHaC Part 2

Need to think up a clever name for this.

So following-up from my last post , I did some experiments and realized that I was making it more complicated than it had to be.

- There’s no need to “seed” the data, if you have the hash, then you already
*know*when you’ve found the right source data (the hash will match,**duh**) - Using random input data doesn’t make sense because you could theoretically be searching forever, as opposed to having a finate (if very long) search by simply incrementing through all possible input combinations

Since my original post I’ve looked into a number of hash functions and learned more about the field of study. I still didn’t find a function that suits my purpose, but at least I know what to call one that would. What I’m looking for is a hash function that is:

- Collision-resistant (or ideally. collision-proof)
- Not especially Preimage attack resistant
- Suitably large range

More broadly, I want a hash function that is fast to hash and not resistant to being reversed. Unfortunately most collision-resistant hash functions are designed for cryptographic applications where reversability is undesirable. So I’m still on the lookout for a hash function that suits my oddball needs.

On the upside I’ve seen several conversations that indicate even a brute-force approach to what I’m trying to do may be feasable due to newer technology that is becoming more commonplace (GPU’s and FPGA). Also it’s worth noting that what I have in mind is almost trivial for a quantum computer , so I’ve got that to fall-back on.

For now I’m going to plow ahead using existing (if not ideal) cryptographic hash functions and see if I can at least demonstrate results with small input data. If that works, then I’ll consider it proof-of-concept, and I can look deeper at accelerating the reversing process as well as selecting/designing a hash function more suited for the application.

--

// jjg