Is it possible to reverse a sha1?

Question

Is it possible to reverse a sha1?

I'm thinking about using a sha1 to create a simple lightweight system to authenticate a small embedded system that communicates over a unencrypted connection.

Let's say that I create a sha1 like this with input from a "secret key" and spice it with a timestamp so that the sha will change all the time.

sha1("My Secret Key"+"a timestamp")

Then I include this sha1 in the communication and the server, that can do the same calculation. And hopefully nobody would be able to figure out the "secret key".

But is this really true?

If you know that this is how I did it, you would know that I did put a timestamp in there and you would see the sha1. Can you then use those two and figure out the "secret key"?

secret_key = bruteforce_sha1(sha1, timestamp)

Thanks Johan

---

Note1: I guess you could brute force in some way, but how much work would that actually be?

Note2: I don't plan to encrypt any data, I just would like to know who sent it.

Answer 1

I believe the accepted answer is technically right but wrong as it applies to the use case: to create & transmit tamper evident data over public/non-trusted mediums.

Because although it is technically highly-difficult to brute-force or reverse a SHA hash, when you are sending plain text "data & a hash of the data + secret" over the internet, as noted above, it is possible to intelligently get the secret after capturing enough samples of your data. Think about it - your data may be changing, but the secret key remains the same. So every time you send a new data blob out, it's a new sample to run basic cracking algorithms on. With 2 or more samples that contain different data & a hash of the data+secret, you can verify that the secret you determine is correct and not a false positive.

This scenario is similar to how Wifi crackers can crack wifi passwords after they capture enough data packets. After you gather enough data it's trivial to generate the secret key, even though you aren't technically reversing SHA1 or even SHA256. The ONLY way to ensure that your data has not been tampered with, or to verify who you are talking to on the other end, is to encrypt the entire data blob using GPG or the like (public & private keys). Hashing is, by nature, ALWAYS insecure when the data you are hashing is visible.

Practically speaking it really depends on the application and purpose of why you are hashing in the first place. If the level of security required is trivial or say you are inside of a 100% completely trusted network, then perhaps hashing would be a viable option. Hope no one on the network, or any intruder, is interested in your data. Otherwise, as far as I can determine at this time, the only other reliably viable option is key-based encryption. You can either encrypt the entire data blob or just sign it.

Note: This was one of the ways the British were able to crack the Enigma code during WW2, leading to favor the Allies.

Any thoughts on this?

Answer 2

SHA-1 is a hash function that was designed to make it impractically difficult to reverse the operation. Such hash functions are often called one-way functions or cryptographic hash functions for this reason.

However SHA-1 has some recently discovered weaknesses that allow finding an input faster than by doing a brute force search of all inputs. You should consider using something stronger like SHA-256 for new applications.

Jon Callas on SHA-1:

It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off.

Answer 3

In mathematical terms, only bijective functions have an inverse function. But hash functions are not injective as there are multiple input values that result in the same output value (collision).

So, no, hash functions can not be reversed. But you can look for such collisions.

---

Edit

As you want to authenticate the communication between your systems, I would suggest to use HMAC. This construct to calculate message authenticate codes can use different hash functions. You can use SHA-1, SHA-256 or whatever hash function you want.

And to authenticate the response to a specific request, I would send a nonce along with the request that needs to be used as salt to authenticate the response.

Answer 4

Hashes are dependent on the input, and for the same input will give the same output.

So, in addition to the other answers, please keep the following in mind:

If you start the hash with the password, it is possible to pre-compute rainbow tables, and quickly add plausible timestamp values, which is much harder if you start with the timestamp.

So, rather than use sha1("My Secret Key"+"a timestamp")

go for sha1("a timestamp"+"My Secret Key")

Answer 5

It is not entirely true that you cannot reverse SHA-1 encrypted string.

You cannot directly reverse one, but it can be done with rainbow tables.

Wikipedia: A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering a plaintext password up to a certain length consisting of a limited set of characters.

Essentially, SHA-1 is only as safe as the strength of the password used. If users have long passwords with obscure combinations of characters, it is very unlikely that existing rainbow tables will have a key for the encrypted string.

You can test your encrypted SHA-1 strings here: http://sha1.gromweb.com/

There are other rainbow tables on the internet that you can use so Google reverse SHA1.

Answer 6

No, you cannot reverse SHA-1, that is exactly why it is called a Secure Hash Algorithm.

What you should definitely be doing though, is include the message that is being transmitted into the hash calculation. Otherwise a man-in-the-middle could intercept the message, and use the signature (which only contains the sender's key and the timestamp) to attach it to a fake message (where it would still be valid).

And you should probably be using SHA-256 for new systems now.

sha("My Secret Key"+"a timestamp" + the whole message to be signed)

You also need to additionally transmit the timestamp in the clear, because otherwise you have no way to verify the digest (other than trying a lot of plausible timestamps).

If a brute force attack is feasible depends on the length of your secret key.

The security of your whole system would rely on this shared secret (because both sender and receiver need to know, but no one else). An attacker would try to go after the key (either but brute-force guessing or by trying to get it from your device) rather than trying to break SHA-1.