0
$\begingroup$

I'm looking for a hash algorithm thats output can be reversed back into the input in a reasonable amount of time (a day or less) using a decent consumer computer. If anyone has any information on this, it would be very much appreciated.

Edit: After reading some of the comments and answers on this post, I feel I should clarify: I'm looking for a hash algorithm where it is relatively easy to reverse a hash into an input that is one byte larger than the hash. For example, if the hash output is 32 bytes, and the input was 33 bytes, I'd like to know if there's a hashing algorithm where it's possible to reverse the output into the input in a situation like this.

$\endgroup$
5
  • $\begingroup$ Generally finding pre-images of hash function outputs is not possible. The algorithm needs to be terribly broken for that to happen. Of course, you would not be able to reconstruct a movie, say "Species", from a 32 byte hash result - even if you wanted to. $\endgroup$
    – Maarten Bodewes
    Commented Mar 19, 2019 at 0:54
  • 2
    $\begingroup$ Could you specify the aim? Although some well known Cryptographic hash functions has no more collision resistance, MD5 and SHA1, there is no known pre-image attack on those. $\endgroup$
    – kelalaka
    Commented Mar 19, 2019 at 8:46
  • 1
    $\begingroup$ Maraca comes to mind. $\endgroup$ Commented Mar 19, 2019 at 15:14
  • 2
    $\begingroup$ There is a difference between a "hash algorithm that the output can be reversed back to the input" versus a "hash algorithm that the output can be reversed back to an input", because a hash can have multiple different inputs that result in it. You may need to clarify which of these your question is about. $\endgroup$
    – Ella Rose
    Commented Mar 19, 2019 at 15:58
  • $\begingroup$ Perhaps 2-pass Snefru? $\endgroup$ Commented Mar 19, 2019 at 16:01

1 Answer 1

1
$\begingroup$

Depending on what you want to do, maybe you can take a cryptographic hash function and truncate it. Adjust the length of the truncation to how much effort you want the preimage calculation to be. This is a valid way to create a proof-of-work mechanism. For example, if you want to require a party to perform about $2^{m+n}$ operations where $2^m$ is the estimated cost of hashing a very short string, then:

  1. Generate a random $s+n$-bit string and calculate its hash $h$.
  2. Send the hash $h$ and the first $s$ bits of the string and request a preimage.
  3. Read back a string and check that its hash is $h$.

(The salt length $s$ needs to be sufficiently long to prevent pre-computing possible inputs.)

With any cryptographic hash function in good standing, and even with most of the ones in bad standing such as MD5, the fastest way to find a preimage is brute force searching among all $n$-bit strings.

If proof-of-work is not what you're after, then maybe you can use a non-cryptographic hash, for example a CRC. In general, hash functions that aren't specifically designed to be cryptographic hashes have a low probability of accidental collision (but it's easy to craft a collision deliberately), and they're easy to invert.

Of course, “inverting” the hash will find a preimage, not necessarily the string you started with.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.