Encryption Cannot Be Reversed?

Question

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)));
}

Answer 1

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.

Answer 2

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).

Answer 3

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.