Can a deterministic hashing function be easily decrypted? [duplicate]

Answer 1

No. At least not easily.

SHA1 is still considered cryptographically secure. A hash algorithm is secure if it is easy to compute one way, but very hard (exhaustive search) to compute the other way. It is true that every time you encrypt a specific phrase, it will result in the same hash, but there are infinite phrases that will also hash to that same value. The security comes from not knowing what those other phrases are until you run them all through the SHA1 function.

Answer 2

That it encrypts the same text the same way every time is the whole point of a hash. It's a feature.

If I have a database of hashes of passwords, then I can check that you entered the correct password by hashing it and seeing if the hash matches what I have in the database for you. But if somebody stole my database of hashes, they won't be able to figure out what your password is unless they accidentally stumble upon some plain text that hashes to that value.

Answer 3

General answer

A cryptographic hash function cannot be easily reversed. This is why it is also sometimes called a one-way function. There is no going back.

You should also be careful about calling this 'decryption'. Hashing is not the same as encryption. The set of possible hash value is typically smaller than set of possible inputs so multiple inputs map to the same output.

For any hash function given the output you can't know which of the many inputs was used to generate this particular output.

For cryptographic hashes like SHA1 it is very difficult to even find one input that produces that output.

The simplest way to reverse a cryptographic hash is to guess the input and hash it to see if it gives the right output. If you are wrong, guess again. Another approach is to use rainbow tables.

Regarding using hashing to encrypt SSNs

With your use case of SSNs an attack is feasible due to the relatively small number of possible input values. If you are worried about people getting access to SSNs then it might be best to not store or use the SSN at all in your application, and in particular do not use them as an identifier. Instead you could find or create another identifier, for example an email address, a login name, a GUID or just an incrementing number. It can be tempting to use the SSN as it is already there and at first glance appears to be a unique unchanging identifier, but in practice using it just causes problems. If you absolutely need to store it for some reason then use strong non-deterministic encryption with a secret key and make sure you keep that key safe.

Answer 4

Encrypting and hashing are two different things.

Hashing simply digests the string into a number. Encryption preserves the contents of the string so that it can later be decrypted. There is no method from getting the original string from a hash. The contents are just not there.

Answer 5

A good hash is one way, meaning you shouldn't be able to go backwards. The point is to provide a key of a string without revealing the string. For instance, this is a good way to match passwords without storing a password. Instead, you store a hash and compare the resultant hash of inputs.