3

Take the following sequence, for example:

  1. hello! = string a

  2. SHA-256 of a: ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4615fef4fec3a308b = b

  3. SHA-256 of b: cb3f2ef7b1de2072e0f5a760622c43c73a6d49da55d0dbcb7cd00dd1933d5302 = c

  4. SHA-256 of c: 9105672626045b178ecc277254e38a54bdbb2c9676f6d5882d9e574de1486523 = d

My questions:

  1. Can "c" be reversed to get "b" above? I read someone said it can be reversed but didn't give details. if it can be reversed, I want to be able to understand how.

  2. I'm considering two methods of attacking iterated hashes.

    Method #1: It will take input in above example, "b" and convert it to SHA-256 hash "c", it will further convert it in SHA-256 hash "d" and so on up to "n". It will, at each conversion, compare each hash to a list of hashes (set1 or set2 etc). If match is found, it will pause and in a text file save (chronologically) last 100 hash iterations it generated, automatically. At pause it will give option to further continue the instance or stop. While running, it will tell the current iteration no. In case of power cut (5min backup) it will pause and when power is restored it will be able to start from where it started. At the beginning, it will give an option to save all hashes (chronologically) in a text file (for dictionary), and ask for how much SSD space to use, after that space is used, it will stop saving but continue running.

    Method #2: It will randomly generate a 64-character hexadecimal string and then generate a SHA-256 hash from this string, and then compare the hash with a list of hashes. It will loop until match is found. In the same instance it will not regenerate the string of which hash it has already been compared. It will also have every feature of software/method #1, like giving an option to save all strings and hashes in a text file on SSD, what to do in power cut, pause or stop, iteration no. etc.

  3. In your opinion, which has better chance of cracking: running short (few hours) instance of either method and comparing against various sets of hashes one by one like set1, set2 etc., or running instance for longer (few days) on one set of hashes?

Breaking any hash from any set of hashes is the goal.

6
  • 2
    It looks like you are treating the hexadecimal values above as text strings. When dealing with hash functions and hexadecimal values, generally the hex values are decoded into raw bytes, then these raw bytes are hashed. Commented Mar 12 at 21:24
  • 4
    This question is similar to: Is it possible to reverse a hashed password?. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. Commented Mar 12 at 21:25
  • 1
    This is not a good question for many reasons. But to point out some aspects: please don't ask multiple questions at the same time but focus on a single one. Product recommendations are off-topic here. Please do your own research first - there are lots of information about reversing hashes. Please provide sources you've used instead of "i read someone said " Commented Mar 12 at 21:28
  • 1
    Product recommendations are explicitly off topic here, see the help center. Commented Mar 12 at 21:29
  • Your question consists of two questions; one (product recommendations) is off topic, and the other is a duplicate. Commented Mar 13 at 0:25

1 Answer 1

4

You cannot go back from c to b. Given a SHA-256 hash y, there's no (known) way of efficiently finding a preimage x such that sha256(x) = y. This is called preimage resistance and is a fundamental property of cryptographic hash functions (like SHA-256).

The only way to “reverse” a SHA-256 hash (in the sense described above) is through brute-force: You have to keep trying different preimages x until you find one which maps to the given hash y. Of course this only works if the search space of possible preimages isn't too large. For example, the brute-force tool hashcat can calculate around 28 billion hashes per second on an Nvidia RTX 5090 GPU.. If you assume the preimage x is a word from a dictionary (like Webster's Dictionary with around 470,000 entries), then it only takes a fraction of a second to try out every possible word. However, if the preimages can be more complex, a brute-force attack might take much longer or even be impractical. You can calculate the maximum required time yourself: If you have a string of n characters from an alphabet of size m, then there are m^n possible combinations. For example, an 8-character alphanumeric string (English letters a, ..., z, A, ..., Z and digits 0, ..., 9) leads to (26 * 2 + 10)^8 possibilities (around 218 trillion) . Trying out all of them at a rate of 28 billion hashes per second would require roughly 2 hours. The bigger the alphabet and the more characters, the longer it takes.

Brute-forcing random 64-character hexadecimal strings as you suggested in method 2 is absolutely hopeless. The resulting search space is gigantic (16^64), and you have practically no chance of ever finding a suitable preimage.

So method 2 isn't an option. Method 1 might be, but this depends on the original input strings and the maximum number of iterations. You can calculate yourself how long you would need to, for example, try out all possible 8-character alphanumeric strings with 100 hash iterations.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.