So, if you have a website, and a user signs up, you store his password as a hash. When they log in, your website takes the submitted password, hashes it, and compares hashed submission to the stored hash, right?
Yes, with three additional details in the standard modern way of doing this:
- The password reaches the website TLS-encrypted; it's decrypted before hashing.
- Salt (random drawn on password registration, or/and the username/email) is hashed together with the password, and stored along the hash of the password by the server.
- It's used a purposely slow, hopefully memory-hard iterated hash designed for passwords, like Argon2. This is designed as a protection in case the server lets the list of hashes and salt leak (such leaks happen routinely). This precaution makes it harder to find the password (or more exactly, an acceptable password most likely the original one) in a dictionary of usual passwords, by hashing candidates passwords and salt and comparing to the password hash, just as the server does to check a password on logon.
Say you are hashing a sentence using SHA-256, do you EVER decrypt such a hash, or even have the ability to?
No. For one, "decrypt" is not the correct term for finding the input of a hash function given it's output; the correct term is "reverse". And, a hash is designed to be irreversible in normal operation. If the hash's input is unknown and chosen randomly in a large set, and the hash design good, it's not practically possible to reverse the hash.
Whatsapp says that my messages are encrypted. So, if I encrypt them as I send them, how does the other persons device decrypt them?
Hashing is not the same thing as encryption. Hashing transforms a message in a way that is designed to be irreversible, and does not use a key. Encryption transforms a message according to an encryption key, in a way reversible by one with the decryption key.
The decryption key must be secret, else the goal of encryption (hiding what's been encrypted to adversaries not knowing the decryption key) is not met. In symmetric encryption (e.g. AES-GCM), the encryption and decryption keys are the same. In asymmetric encryption (e.g. RSA, ECIES), they are different: the encryption key can be made public, and is called the public key; the decryption key is the private key.
When you send a message with a modern application that uses asymmetric encryption (like Whatsapp), here is the big picture:
- Your app draws a random symmetric message-unique key.
- Your app encrypts the message using symmetric encryption with this message-unique key, and the result is sent.
- Your app repeatedly encrypts the message-unique key towards each intended recipient, using asymmetric encryption (e.g. ECIES) and each of the intended recipient's public key, and the results are sent.
- When a recipient needs to decrypt the message, their app first gets the encrypted message-unique key encrypted under their public key, and deciphers it (per asymmetric decryption) using their private key, yielding the message-unique key.
- The recipient's app gets the encrypted message, decrypts it per symmetric decryption using the message-unique key, then display the decrypted message.
The primary mechanism protecting the confidentiality of the message is symmetric encryption. Asymmetric encryption protects the confidentiality of the message-unique key, thus indirectly protects the confidentiality of the message. Hashing typically is used internally as a building block in some of the steps, but is not the mechanism that encrypts the message or the message-unique key.
