8

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)));
}
user1477388
  • 279
  • 1
  • 10
  • 4
    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)? –  Jul 08 '13 at 18:34
  • Does my edit answer your question? I am not sure what you mean. – user1477388 Jul 08 '13 at 18:36
  • 13
    `SHA256` is a [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function), not an encryption algorithm. It is a [one way function](https://en.wikipedia.org/wiki/One-way_function). –  Jul 08 '13 at 18:37
  • 1
    Obligatory disclaimer: salt the hash (http://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 08 '13 at 20:13
  • 10
    Hashing is like a meat grinder. You can turn a cow into ground beef, but not the other way around. – Neil McGuigan Jul 09 '13 at 01: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 09 '13 at 21:44
  • @ott Also good points. Thanks. I guess I was talking about "hashing" and not actually "encryption." – user1477388 Jul 10 '13 at 11:03
  • @bye: plus you loose 98% of the meat during that process and are left with only 2%. Hard to build a complete cow fom that. – JensG Nov 21 '14 at 09:54

3 Answers3

41

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.

Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • 3
    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 08 '13 at 18:44
  • 21
    @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 08 '13 at 18:45
  • 2
    Looks like this has some good insight to my "inability to believe that these can't be reversed somehow" http://security.stackexchange.com/questions/11717/why-are-hash-functions-one-way-if-i-know-the-algorithm-why-cant-i-calculate-t Not that I want/ have any need to reverse them; I'm just curious. – user1477388 Jul 08 '13 at 18:51
  • @user1477388: Yeah, that's a much more technical and in-depth explanation of why hash functions aren't easily reversible, mathematically. I was explaining more about why hash functions are *designed to not be easily reversible.* – Mason Wheeler Jul 08 '13 at 18:55
  • 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 08 '13 at 19:44
  • 2
    @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 09 '13 at 07:42
  • 1
    @Katana314: What you describe is called "salting". – tdammers Jul 09 '13 at 07:44
  • 2
    @tdammers What you're describing is [nicely visualized in this comic](http://xkcd.com/936/). – Sean McSomething Jul 23 '13 at 22:41
  • Please don't advise people to use generic hashes like SHA256 for password storage. Passwords should really use bcrypt or similar. – juhist Sep 20 '22 at 16:45
  • @juhist Not sure where that's coming from, seeing as how I didn't mention SHA anywhere... – Mason Wheeler Sep 20 '22 at 16:52
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).

KeithS
  • 21,994
  • 6
  • 52
  • 79
  • 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](http://en.wikipedia.org/wiki/Avalanche_effect). – user Jul 08 '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 08 '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. – user Jul 09 '13 at 07:18
-2

I've got a plan for a non-reversible transform. (Given the transform its still impossible to put it backwards.) It's for a unique identifier thing for an application.

I'm planning on using composites, to make it non-reversible.

But between each addition, I put an even and odd check of all members going into the sum, so unless u know what the composites are, you cant cant back through a sum section backwards, because there is multiple options for what they could be, and each sum step you go it compounds in possibilities for what it could be.

Each check before each sum node, gets xorred together at the end, so they all become into the result of 1 and 0 at the end, inbetween the composite conversions (summing.)

Just have to make sure only 0.000000000000001% of the codes end up valid somehow, im not sure what it is, maybe u get that by not using even and odd, you actually make it positive 1 in every 10 instead of every second.

But P=NP will still be able to crack it just by trying all possibilities, similar to RSA.

lennon310
  • 3,132
  • 6
  • 16
  • 33
Robot' nik
  • 1