9

I am under the impression that an encrypted string cannot be decrypted so the original value is lost forever.

However, if the following string always equals "dominic" (my name), then can't there be some logical way to reverse it; being as it's not random nor is it based on the date/time, but there is a logical method to it?

0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=

No matter what or how many times I encrypt "dominic" (string), it always equals as above. So, shouldn't there be some way to decrypt a string like that?

Example of what I'm talking about:

public string EncryptPassword(string password)
{
    return Convert.ToBase64String(
        System.Security.Cryptography.SHA256.Create()
        .ComputeHash(Encoding.UTF8.GetBytes(password)));
}
  • 3
    Are you talking about the cryptographic hash of a name (often used in passwords)? or the encryption (which is intended to be decrypted by an authorized person)? – user40980 Jul 8 '13 at 18:34
  • 11
    SHA256 is a cryptographic hash function, not an encryption algorithm. It is a one way function. – user40980 Jul 8 '13 at 18:37
  • 1
    Obligatory disclaimer: salt the hash (en.wikipedia.org/wiki/Salt_(cryptography)). Furthermore SHA256 tends to be too fast to not have problems with brute-force attacks using for example GPUs. It would be recommended to use something like PBKDF2 or scrypt. – Maciej Piechotka Jul 8 '13 at 20:13
  • 7
    Hashing is like a meat grinder. You can turn a cow into ground beef, but not the other way around. – Neil McGuigan Jul 9 '13 at 1:26
  • 1
    Are you confused by public-/private-key encryption? If someone else encrypts a message with your public key, he cannot decrypt that message by himself. Only you can decrypt this - and maybe the NSA, Mossad, FSB and the Tiroler Geheimdienst. – ott-- Jul 9 '13 at 21:44
39

Encryption can always be reversed. The point of encryption is to take a message and encode it with a secret key so that only another person who has the key can reverse the encryption and read the message.

What you're looking at here is hashing, which is not the same as encryption, though cryptographic techniques are often used in implementing hashes. The idea of a hash is that it uses complicated mathematical techniques to build a new value that maps to an old value, which is repeatable. There's no key, and it's not meant to be reversed. A cryptographically strong hash is created with the mathematical property that, if you have value A whose hash is value B, it's very, very difficult to intentionally create another value C that also hashes to B.

Hashes don't need to be reversible, because they're used for authentication. If you give me a username and a password, you really don't want me storing that password in my database, because if someone hacks in and gains access to my database, they could get ahold of your password! So instead, I'd store the hash of your password in the database. Then when you log in, I check to see if there's a username that matches yours, with a password entry that matches the hash of the password you sent, and if so you're authenticated, because it's very difficult to create a hash collision (two values that hash to the same value) with a good hash, so I'm almost perfectly certain that the password you used is the right one.

The other property of a strong cryptographic hash is that it's very difficult to reverse. You know that the value 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE= is the hash for "dominic" because you just worked it out, but if you didn't know that, and didn't know where to start looking, and all you had was 0WrtCkg6IdaV/l4hDaYq3seMIWMbW+X/g36fvt8uYkE=, it could literally take you billions of years to figure out that the original was "dominic", if the hash is a good one. Again, this is useful to prevent collateral damage in case a password list gets stolen.

  • 2
    Couldn't I just take a list of known words and loop through until I found a hash match? Is this why websites suggest adding uppercase letters and numbers to your passwords to make them more secure? – user1477388 Jul 8 '13 at 18:44
  • 15
    @user1477388: Yes, that's exactly why websites suggest that. That's a well-known way of attacking hashed passwords: it's called a "dictionary attack," for obvious reasons, and using words that aren't in the dictionary is an important step for being secure against them.. – Mason Wheeler Jul 8 '13 at 18:45
  • 1
    Looks like this has some good insight to my "inability to believe that these can't be reversed somehow" security.stackexchange.com/questions/11717/… Not that I want/ have any need to reverse them; I'm just curious. – user1477388 Jul 8 '13 at 18:51
  • 3
    Another suggestion is to add something unique to each password before it's hashed. A one-character password difference makes a completely different hash, the idea being that all your hash results will be unique. Otherwise, if a hacker discovers the hash for the word "password123", then they would know to use that against ALL usernames with that particular hash. It sounds like you have a good head for this sort of thing, though, so good luck. – Katana314 Jul 8 '13 at 19:44
  • 1
    @MasonWheeler: using words that aren't in the dictionary isn't really necessary, especially considering how the "dictionary" used in a typical attack is nothing like the Oxford dictionary, but rather a list of strings known to be used in passwords often. Rather than trying to avoid these words, it is better to pick, say, 5 random words from a list of 2000 or so words: such a passphrase, even if the 2000-word dictionary is known, takes almost 100 times longer to brute-force than 8 random characters out of 64. – tdammers Jul 9 '13 at 7:42
9

What you are doing is not "encryption", per se; it's "hashing". The principal difference between the two is that encryption is easily reversible (with the correct key of course), while hashing is designed to be extremely difficult to reverse in any circumstance other than knowing the original message in the first place.

In theory, hashes simulate a "random oracle", a hypothetical homunculus with an eidetic memory and a way to generate perfectly unique, perfectly random numbers with no upper range limit. You'd give this little man a message, and one of two things would happen; either he's never seen the message before, in which case he generates a new random number and gives that to you as the digest, or he has seen that messsage before, and so he remembers and gives you the number he generated when he saw it the first time. In that theoretical model, there is zero relationship between a message and its digest, and with no single number ever appearing twice from the RNG there's no possibility for a collision.

Unfortunately, we don't have an ideal random oracle; the idea has practical impossibilities for a digital implementation, such as the ability of the oracle to efficiently store and efficiently recall every message ever hashed by anyone anywhere, and the ability of the clients to accept a number that could be hundreds or thousands of decimal digits in length. Instead, we have hash functions, which are irreversible (one-way) mathematical operations that work on the message itself, to create a deterministic transformation (same message => same hash) with no apparent relationship between the hash and the original message. As mentioned in the comments, there should also be no predictable change to the hash value produced by making systematic changes to the message; ideally, each bit of the digest would have a 50% chance to change, given a change to a single bit of the message.

There are many uses for a hash function; they're used for challenge verification (think login credentials like passwords) without the need for both parties to know the plain text secret, and they're used as checksums to verify that a message hasn't been tampered with or corrupted. They're also used in so-called "proof of work" scenarios; computational tasks that are difficult to complete but easy to verify.

If you were ever to find a way to efficiently reverse a SHA256 hash digest to produce a message (any message) that would result in that hash, it would be a proof by demonstration that in fact the hash is fundamentally broken. SHA256 is, in fact, believed secure, meaning there is no documented method, no matter how practical, to begin with a hash digest and produce a colliding message that requires less work than simply trying every possibility (which for SHA-256 is ideally 2^256 ~= 10^77 possibilities).

  • It might be worth mentioning too that in an ideal hash function, a one-bit change in the input should result in a change of 50% of the output bits. It's called the avalanche effect. – a CVn Jul 8 '13 at 20:44
  • 2
    @MichaelKjörling: Precisely put, one should expect each bit to change with 50% probability, which is different from (but implies) expecting 50% of the bits to change, on average. – Dietrich Epp Jul 8 '13 at 23:14
  • @DietrichEpp Indeed, and the Wikipedia article I linked to makes that clear, but it is easier for the end-user to quantify the number of bits changed between two inputs. – a CVn Jul 9 '13 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.