Are hash functions one-way?

Question

I have heard that we can convert any text to hash code , but hash code can't be converted back to text without brute force.

Suppose we consider the text "mal". The hash codes of the individual letters are

m= 6f8f57715090da2632453988d9a1501b

a= 0cc175b9c0f1b6a831c399e269772661

l= 2db95e8e1a9267b7a1188556b2013b33

Those of the prefix "ma" and of "mal" itself are

ma= b74df323e3939b563635a2cba7a7afba

mal= 749dfe7c0cd3b291ec96d0bb8924cb46

Each hashcode has 32 elements, which can be either numbers from 0 to 9 or letters from a to f.

What I observed was some when we add a letter some numbers are kept like it is just changing it's order. Is there some logic in it? Is there some easier method?

Answer 1

If you could easily convert from the hash code back to text then this would make the hash code useless for cryptographic purposes. In order to be secure, a cryptographic hash function should be a one-way function, which is impossible (for all practical purposes) to invert.

Another complication is that the hash function output is a fixed length - in your case, your hash values are $128$ bytes bits each. They are printed out in hexadecimal as a string of $32$ characters, and each character represents $4$ bytes bits. But the input to the hash function can be text of any length at all. So there will be many different text strings which give the same hash code (although almost all of these strings will be meaningless nonsense).

If you know that the input text is a single character then you can use a brute force attack - run the hash function on all possible single character texts until you get an output that matches the hash value that you are looking for. The same approach will work for short texts of just a few characters. But if your text could be hundreds or even thousands of characters long then a brute force approach is not practical, because the number of possible texts is much too large.

Answer 2

Well, there is obviously a system. Someone wrote code to calculate the hash codes for strings, and that is the system that the hash code follows.

For normal software development purposes, it's Ok if there is a system that you can recognise, as long as different strings are mapped to different hash codes most of the time. For cryptography, for example when you calculate a hash code for a password, you want hash codes where it is practically impossible to determine the string from the hash code.

For a cryptographic hash, given a hash h, the only way to find a string s with hash(s) = h is to try out all possible strings s calculating hash(s) for each, until we find an s with hash(s) = h. Given a cryptographic hash for the string "1234", you would find such an s quickly.

For ordinary hash functions, if you are given how the hash code is calculated, it is often possible to calculate which is the shortest string s with hash(s) = s. However, any function that maps from an infinite set (strings) to a finite set (fixed length hash codes) must allow many strings to map to the same hash code. So if you map 500 bit strings to 256 bit hash codes, you cannot possibly determine which string was hashed, because many strings have the same hash code.