# Is there an outdated or insecure hash algorithm thats output can be easily reversed back into the input?

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.

• 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. Mar 19 '19 at 0:54
• 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. Mar 19 '19 at 8:46
• Maraca comes to mind. Mar 19 '19 at 15:14
• 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. Mar 19 '19 at 15:58
• Perhaps 2-pass Snefru? Mar 19 '19 at 16:01

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.