Jason J. Gullickson

Jason J. Gullickson

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:

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

Preposter.us | Github | Twitter | Ello | Google+ | Facebook