History UsefulNotes / Encryption

* Biometrics can provide convenient access to devices and services, but for security you're probably better off without it. In addition to making you directly a target (consider the story of someone having a car stolen by having their finger cut off to unlock it), if that data is lost or stolen, you can't exactly go and order a new set of fingerprints. Some jurisdictions will allow the authorities to force users to grant access to a device using biometric data, or forcibly obtain that data during the course of their work (e.g. taking fingerprints upon arrest at a police station), and then try to use that information to gain access to a confiscated device, but users are ''not'' forced to disclose keys and passwords. This means that there are places where biometrics provides a huge backdoor that would not otherwise exist if using normal passwords or PINs. You also can't claim to have forgotten your fingerprint.

* Biometrics can provide convenient access to devices and services, but for security you're probably better off without it. In addition to making you directly a target (consider the story of someone having a car stolen by having their finger cut off to unlock it), if that data is lost or stolen, you can't exactly go and order a new set of fingerprints.

And finally, a couple of bonus tips:

* "Security questions" are essentially anything but. In many implementations they act as weaker second passwords, and as a backup way of authenticating a user. There is no sense in using a near uncrackable password like "xBzZxTEDCem6JQGnbwEf" if an attacker can claim to have 'forgotten' the password, and then have to answer the question on your birthplace to gain access to the account, information that can often be guessed or retrieved from social media. If you are forced to use a "security question", the best solution is to make up the answer using another randomly generated password and store this information in a password manager along with your main password.
* Biometrics can provide convenient access to devices and services, but for security you're probably better off without it. In addition to making you directly a target (consider the story of someone having a car stolen by having their finger cut off to unlock it), but if that data is lost or stolen, you can't exactly go and order a new set of fingerprints.
* Note the difference between multi-factor authentication and mere multi-step authentication. Multi-factor authentication requires at least two of the following: what you know (passwords, PIN, etc.), what you have (smart card, security token), and what you are (biometrics, something else unique about you). If for instance, you log in via your smartphone to a place that sends you a verification code via text message, this isn't multi-factor authentication per se. Sure you need a phone to receive text messages, something a PC normally can't do, which might suggest it satisfies the "what you have" requirement. But authenticating via a smartphone means it's the same device, so it doesn't count. Not to mention, it's relatively easy to intercept text messages as long as the attacker knows your phone number. To have actual multi-factor authentication, you should use something like a security key fob (such as a Yubikey), and while the previous point about biometrics are valid, they also count as "what you are," which can increase security if used correctly.

One major problem with encryption of these types is the concept of ''diffusion''. With simple encryption, while the data may look different from the original, the ''patterns'' within the original can still remain. For example, if you encrypt a picture of the TV Tropes logo, the output will still resemble the logo, even though none of the colors are the same as the original (another example can also be seen in Figure 2 in [[https://www.kingston.com/en/blog/data-security/xts-encryption this article]]). To get around this, various methods use some form of scrambling the input in a reversible way such that no easily discernible pattern can be made in the output.

*** A special note on using Argon2 and Bcrypt for password storage. These two algorithms are known as ''slow'' hashing algorithms. Which begs the question, why would you want something slow? It's because the cost to run these algorithms to generate rainbow tables is prohibitively expensive compared to the server running them. The server only needs to run these algorithms when either storing a new password or comparing an inputted one. Assuming nobody's actively trying to attack the system by repeatedly submitting passwords (which your server should have a rate limiter on clients), the server isn't going to be busy with these. But for an attacker who wants to generate rainbow tables or try to brute force someone's password, with a high enough ''work factor'', even with a powerful GPU, the number of guesses per second drops dramatically. This is also why if you don't have access to these two for some reason, PBKDF2 with a high iteration count works. But the overall takeaway is, make it hard for the attacker to generate guesses, because 1 second for a server to generate a response is nothing compared to 1 billion seconds an attacker could see trying to make a rainbow table.

** On the developer side, NIST and OWASP regularly publish lists of algorithms recommended for application usage.[[labelnote:Which?]]At the moment of this edition, some recommended algorithms are (1) any proven [[https://en.wikipedia.org/wiki/Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD) AEAD]] implementation of [[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES]] (for symmetric crypto), (2) [[https://en.wikipedia.org/wiki/RSA_(cryptosystem) RSA]] and [[https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman ECDH]] (even better) for asymmetric crypto, (3) [[https://en.wikipedia.org/wiki/SHA-2 SHA-256]] at a minimum for hashing, (4) [[https://en.wikipedia.org/wiki/Argon2 Argon2]] or [[https://en.wikipedia.org/wiki/Bcrypt bcrypt]] for password hashing (use [[https://en.wikipedia.org/wiki/PBKDF2 PBKDF2]] with a high iteration count if you can't use either) and (5) [[https://en.wikipedia.org/wiki/Hardware_security_module HSMs]] for crypto operations if available (if not, rely on the underlying OS's functions).[[/labelnote]] Algorithms like [=DES=], [=MD5=] and [=SHA-1=] are already declared insecure due to brute-force attacks on them being feasible, so don't use them unless you have to provide compatibility with legacy systems.

The simplest method of cracking a password is known as "brute force": trying every possible password. The problem with this is that it can take a very long time to find the right password. The number of possibilities for a password increases with every character added to the length of the password and every character added to the range of options. For example, if you wanted to to find a password that was six (uppercase only) letters long, you might have to try 26[[superscript:6]] = 308,915,776 possible passwords. At the rate of a thousand guesses per second, it would take three and a half days to run through the list. Trying every ''seven''-letter password at the same rate would take three months. If, instead of uppercase letters only, the passwords use lowercase letters, uppercase letters, and digits (26 + 26 + 10 = 62 options for each character), a six-character password requires 1.8 years to exhaustively search at this rate, and a seven-character one requires 111.5 years.

The problem for the user is that memorizing a truly random string of characters is very difficult. It's easier to use actual words as passwords. However, this is more vulnerable to brute-force attack: the number of words in the dictionary is ''much'' smaller than the number of random combinations of characters. Using odd spelling (such as "leetspeak" substitutions of other characters for letters) and using unusual words makes a dictionary attack more difficult; however, sophisticated attackers will use an exhaustive vocabulary and try a range of variations for each word. Ultimately, this adds very little security and makes the passwords harder to remember, meaning people are more likely to use a simpler password. Any trick you can think of to make a 'secure' but memorable password is one that [[https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ will be accounted for]].

Another problem is the incredible growth of computing power over the past few decades. The example above for a seven letter password has around 8 billion combinations. Sounds like a lot, right? And at a thousand guesses a second, it would be. Except we can do a lot more than that. For example, if we have our passwords secured with an MD5 hash (don't do this!), a ''single'' RTX 4090 can calculate 164 ''billion'' hashes a ''second''. A cluster of 12 GPUs is just shy of 2 ''trillion'' a second. To say nothing of the resources available with cloud computing, for those willing to open their wallets -- and for the right target, it can be worth it.

The problem for the user is that memorizing a truly random string of characters is very difficult. It's easier to use actual words as passwords. However, this is more vulnerable to brute-force attack: the number of words in the dictionary is ''much'' smaller than the number of random combinations of characters. Using odd spelling (such as "leetspeak" substitutions of other characters for letters) and using unusual words makes a dictionary attack more difficult; however, sophisticated attackers will use an exhaustive vocabulary and try a range of variations for each word.

It is possible to combine randomness and easy memorization using tricks such as remembering a phrase and using the first letter of each word (e.g. "This website will ruin your life" becomes "Twwryl"). Another option is to use a password manager program to store an encrypted database of passwords; the user then only needs to remember one master password to access all the others.

To do this, for login authentication, Alice first gives Bob a nonce. Bob combines this nonce with his password and along with a hashing function (described later), sends the result to Alice. Alice then applies the nonce she generated with the password she got from Bob when Bob created his account and runs it through the same has function. If she gets a match, she knows it's Bob. Every time Bob wants to log in, Alice gives Bob a new nonce.

While using one-time pads to protect a whole conversation is cumbersome, a related idea of throw-away cipher input is the cryptographic nonce ('''n'''umber used '''once'''). This is often used in challenge/response-type authentication. In this method, Alice gives Bob a nonce and asks for a password back. Bob uses a hashing function (a type of one-way encryption function) on his password and the nonce and sends it over to Alice. Alice applies the same hashing function with the password with the nonce generated and if it matches Bob's response, then she knows it's Bob. Every time Alice asks for a password, she gives Bob a new nonce. This is to prevent someone from using Bob's old responses (known as a "replay attack"). Therefore, throwing the nonce away each time is the whole point; and because the password is short, the nonce doesn't have to be very long. The nonce doesn't even have to be kept secret.

However, there's a flaw to this. Eve, an eavesdropper, can pretend to be Alice to ask Bob, Charlie, and others for their passwords using the same nonce. From their responses, Eve can try figure out their passwords by brute forcing or using a dictionary of known passwords. To combat this, Bob can also generate a nonce then run the hashing function with his nonce, Alice's nonce, and the password. Then Bob sends his nonce along with the hash function output, and Alice will use Bob's nonce along with her's to generate what should be expected. Since Alice and Bob are both using nonces, Eve will have a harder time figuring out the password.

But if the users of a one-time pad get sloppy and reuse a key for more than one message, it becomes trivial to break. If the keys are not truly randomly generated, it can be broken, too. A number of historical codebreaking successes resulted because somebody tried to use one-time pads but either reused the keys or generated them in a non-random fashion.

The reason one-time pads are unbreakable is that for any conceivable plaintext, there exists a possible key that would produce that plaintext from the encrypted message. This means that if you try to guess what the key is, there are exponentially many more false positives than the real message, and no way to tell a false positive from a true positive.

As mentioned above, the key doesn't have to be a password. For example, in ''Literature/{{Cryptonomicon}}'', two people communicate using the "Solitaire cypher". The cypher uses a deck of cards; their initial arrangement is the key leaving 54! (54 factorial, 54×53×52×...×2×1 = about 2.3 × 10[[superscript:71]]) possible keys and no dictionary to use.

The knowledge of the plaintext or parts of the plaintext (so-called "cribs") can make a cryptanalysis problem exponentially easier. The plaintext - or parts of it - could be acquired by old-fashioned spying or, more inventively, by [[FeedTheMole feeding the mole]]. This is called a "[[https://en.wikipedia.org/wiki/Known_plaintext_attack known plaintext attack]]".

This is where the cryptographic hash function comes into play. A hash function takes the bytes that make up the data, adds them together in a convoluted manner, and spits out a number of fixed size called a ''digest''. That is, for ''any'' input, the function will spit out a value that has the same number of bytes. Hashing, as it's called, is one-way, hence "one-way encryption". That is, theoretically, you cannot map a digest back to its original content because a digest has an infinite number of things that could map to it. This characteristic obviously has the problem that there's an infinite number of things that can map to the same digest, called "collisions". So for a hash function to be suitable for cryptography, it must have a reasonably large digest size to make the chance of a collision prohibitively small. Another characteristic is that for a small change in input, the function must create an output so that no obvious relationship can be made between the two.

There are two main forms of encryption today: symmetric and asymmetric.

''Symmetric'' encryption is the classic form of encryption as is known today. The plaintext is encoded into ciphertext using a secret key; the recipient, to decode the message, must know the secret key that was used to encode it. The name refers to the fact that encryption and decryption are inverse functions and both use the same key to work (thus symmetrical). This was the first form devised -- primitive versions (simple substitutions of one letter for another, or shift-by-x codes like the [[https://en.wikipedia.org/wiki/Caesar_cipher Caesar Cipher]]) go back to ancient times, with increasingly sophisticated variations being developed as [[LensmanArmsRace the arts of codemaking and codebreaking advanced]]. Eventually, the algorithms became so complex that machines (such as the Enigma device used in UsefulNotes/WorldWarII) were required to encrypt and decrypt messages with reasonable speed and accuracy.

''Asymmetric'' encryption is a newer form of encryption, devised in TheSeventies; in this form, the key used to encrypt the message and the one used to decrypt it are not the same. In an asymmetric cipher, each party has a ''pair'' of keys: a '''public''' key and a '''private''' key. If Alice wants to send Bob a message, she uses Bob's public key to encrypt the plaintext, and Bob uses his private key to decrypt it. Public keys, as the name indicates, are not required to be secret; private keys are. In short, encryption and decryption are not inverse to each other in asymmetric encryption schemes, hence the name.

Another advantage of asymmetric encryption is that it can be used in reverse, encrypting a message with your private key to create a ciphertext that anyone can decrypt using your public key. This gives the message a digital signature that proves that the private key owner wrote it, because it was encrypted with a key nobody else knows. The two processes can be combined, so that Alice can send Bob a message that nobody else could have written and nobody else can read.

The biggest practical disadvantage of asymmetric encryption is that you need to "trust" that what you think is the recipient's public key ''really'' is theirs, and that their private key has not been disclosed -- I can pretend to be the President of the United States and send you a public key, and if you mistakenly believe me, you might unwittingly send your top secret messages to me instead of the President and accept my digitally signed messages as if they came from the President. The normal method to verify this is for a third-party public key repository to digitally sign and store usernames and public keys. This does require a third party trusted to be impartial and an accurate record-keeper. Another alternative is a "web of trust", in which people sign each other's keys, so that (for example) Alice can verify that Carol and Dave have signed Bob's key, vouching for the fact that it actually belongs to Bob. Alice then decides whether or not to take their word for it (much as she would if Carol and Dave were vouching for Bob in person).

Another disadvantage of asymmetric encryption is that it is more computationally expensive than symmetric systems. Most secure encrypted channel schemes get around this problem by using the asymmetric encryption solely to transmit a randomly generated one-time symmetric encryption key, then switch to symmetric encryption for the bulk of the transaction.

Security certificates -- the bits of bits that tell us that individuals online are who they say they are -- use the above described digital-signature technique to generate a "seal of approval" that can be read by everyone, but only manufactured by the issuing authority.

The [[http://en.wikipedia.org/wiki/One_time_pad one-time pad]] is a special kind of cipher that is completely unbreakable if used correctly—but very weak if used incorrectly, and also very impractical. The trick is that the secret key must be as long as the plaintext, must be completely random, and must never ever be reused.

But if the users of a one-time pad get sloppy and reuse a key for more than one message, it becomes trivial to break. If the keys are not truly randomly generated, it can be broken too. A number of historical codebreaking successes resulted because somebody tried to use one-time pads but either reused the keys or generated them in a non-random fashion.

Then there is also the problem of communicating the keys, which is even harder than in the normal case because (a) you need as many keys as messages, (b) the keys are as long as the messages.

While using one-time pads to protect a whole conversation is cumbersome, a related idea of throw-away cipher input is the cryptographic nonce ('''N'''umber used '''once'''). This is often used in challenge-response type authentication. With this, Alice gives Bob a nonce and asks Bob for a password. Bob uses a hashing function (a type of one-way encryption function) on his password and the nonce and sends it over to Alice. Alice applies the same hashing function with the password with the nonce generated and if it matches Bob's response, then she knows it's Bob. Every time Alice asks for a password, she gives Bob a new nonce. This is to prevent someone from using Bob's old responses ("replay attack"). Therefore, throwing the nonce away each time is the whole point; and because the password is short, the nonce doesn't have to be very long. The nonce doesn't even have to be kept secret.

However, there's a trick to this. Eve, an eavesdropper, can pretend to be Alice to ask Bob, Charlie, and others for their passwords using the same nonce. From their responses, Eve can try figure out their passwords by brute forcing or using a dictionary of known passwords. To combat this, Bob can also generate a nonce then run the hashing function with his nonce, Alice's nonce, and the password. Then Bob sends his nonce along with the hash function output, and Alice will use Bob's nonce along with her's to generate what should be expected. Since Alice and Bob are both using nonces, Eve will have a harder time figuring out the password.

Suppose you want to store sensitive information for a challenge-response, like a password to an account. Obviously storing passwords in a database in plaintext is highly insecure. You could encrypt the password and store the encrypted version, but this presents several issues:

* If someone dumps the database of the encrypted passwords, you can easily see multiple people have used the same password.

This is where the cryptographic hash function comes into play. A hash function takes the bytes that make up the data, adds them together in a convoluted manner, and spits out a number of fixed size called a digest. That is, for ''any'' input, the function will spit out a value that has the same number of bytes. Hashing, as it's called, is one-way, hence one-way encryption. That is, theoretically you cannot map a digest back to its original content because a digest has an infinite number of things that could map to it. This characteristic obviously has the problem that there's an infinite number of things that can make to the same digest, called collisions. So for a hash function to be suitable for cryptography, it must have a reasonably large digest size to make the chance of a collision prohibitively small. Another characteristic is that for a small change in input, the function must create an output so that no obvious relationship can be made between the two.

Running the password through a cryptographic hash function plus salt solves the three issues noted before with encryption:

Aside for storing passwords securely, a superset of that use is that cryptographic hash functions are used to verify the integrity of any given piece of data. For example, when downloading files off the internet, you want to make sure that the files weren't tampered with. The provider of the file can say say what the hash is and then you can verify it by running it through the same hash function. It would be ''extremely'' difficult for an attacker to change the file in such a non-obvious way to have the hash function spit out the same hash value. Hashing is also used in [[{{UsefulNotes/Bitcoin}} cryptocurrency]] to maintain the integrity of the block chains.

The act of analyzing the cipher and the ciphertext in order to retrieve the original plaintext. It is not true that any ciphertext can be cracked. Using a wrong key can sometimes result in a valid-looking plaintext that is in fact not the correct plain text (one-time pads work this way).

To recover a plaintext from a ciphertext, the key and the algorithm used are required. Having only the ciphertext is the hardest problem: the cryptanalist must guess both the algorithm and the key. This is called a ciphertext-only attack and it requires the experience and the intuition of the analyst, knowledge of the circumstances, the sender, the receiver, current events, etc... While statistical analysis of the ciphertexts could provide information about the algorithm, it requires plenty of ciphertexts or it doesn't give any meaningful information. With modern encryption algorithms, ciphertext-only cryptanalysis is basically impossible no matter how much data you have.

The simplest method of cracking a password is known as brute force: trying every possible password. The problem with this is that it can take a very long time to find the right password. The number of possibilities for a password increases with every character added to the length of the password and every character added to the range of options. For example, if you wanted to to find a password that was six (uppercase only) letters long, you might have to try 26^6 = 308,915,776 possible passwords. At the rate of a thousand guesses per second, it would take three and a half days to run through the list. Trying every seven-letter password at the same rate would take three months. If, instead of uppercase letters only, the passwords use lowercase letters, uppercase letters, and digits (26 + 26 + 10 = 62 options for each character), a six-character password requires 1.8 years to exhaustively search at this rate, and a seven-character one requires 111.5 years.

Of course, if the encryption algorithm itself is weak, even an unguessable password won't help you. Cryptographers consider an algorithm broken if there is a way to figure out the key faster than brute forcing it. Sometimes, this is only of theoretical interest (for example, even with the speedup it would still take longer than the age of the universe). Other times the algorithm is so broken that the key can be recovered quickly and easily. There are a large variety of attack techniques using advanced math, and new cryptosystems are expected to show evidence of resistance to them. If after years of analysis by expert cryptographers there aren't any practical attacks discovered, then it's considered probably secure. That little code you created yourself, however, doesn't stand a chance.

As mentioned above, the key doesn't have to be a password. For example, in ''Literature/{{Cryptonomicon}}'', two people communicate using the "Solitaire cypher". The cypher uses a deck of cards; their initial arrangement is the key leaving 54! (54 factorial, 54×53×52×...×2×1 = about 2.3 times 10 to the 71st power) possible keys and no dictionary to use.

The knowledge of the plaintext or parts of the plaintext (so-called "cribs") can make a cryptanalysis problem exponentially easier. The plaintext - or parts of - could be acquired by old-fashioned spying or, more inventively, by [[FeedTheMole feeding the mole]]. This is called a [[https://en.wikipedia.org/wiki/Known_plaintext_attack known plaintext attack]].

And then (as the xkcd comic at the top of the page illustrates) there's the age-old standby of ''rubber hose cryptanalysis'' -- [[TortureAlwaysWorks beating/torturing]] the key out of a holder. (The name comes from the rather vivid image of the keyholder being beaten across their bare feet with a rubber hose). This does not have a direct counter, but many applications (such as [[https://www.veracrypt.fr/en/Home.html VeraCrypt]]) allow a defense based on [[https://en.wikipedia.org/wiki/Plausible_deniability plausible deniability]] for an encrypted volume to decrypt to a 'decoy', which hides a ''second'' encrypted volume with a different key. Thus, someone coerced into giving up a key can [[InfractionDistraction reveal one secret while hiding a bigger one]]. The interrogator may suspect the presence of a hidden inner volume, but its existence can not be proved or disproved.[[note]]It is technically possible to look for ''clues'' relating to one, normally via forensic analysis of a disk surface, but this is prohibitively expensive and difficult even for governments, and is in no way definitive proof. And even if they do pry the existence of the hidden volume out of you, there's no rule that the "hidden" volume cannot itself be another decoy...[[/note]]

Of course, no encryption could protect you from stupidity. If you ever find yourself in a situation where the secret service is digging through your trash and anything you say might spell your doom if it ever gets in the wrong hands (because, be honest, who ''doesn't'' get into situations like this?), remember the following:

* Keep the keys secret! This is pretty obvious, if someone knows the key, your encryption is ''fucked''.[[labelnote:Why?]]A good cryptosystem only needs the key to be secret to ensure resistance to attacks. If your newest, groundbreaking cryptosystem needs to be kept secret to ensure security, then it's not a good cryptosystem.[[/labelnote]]

* If you're a developer, whatever you do, NEVER make up your own encryption. For that matter, try to avoid writing your own code to implement existing cryptosystems too, and use existing protocols and libraries as much as possible. Encryption is notoriously difficult to get right, and you almost certainly won't.[[labelnote:Why?]]A good cryptosystem is not something you get just with good ideas. There has to be a lot of analysis, testing and study to get something decent. Even opening the box and using an oscilloscope to read voltage levels can reveal things about your cryptosystem an attacker can and will use to break it, so covering all possible attack vectors, getting the math right in all cases and providing for all use cases is not something you can achieve alone and in a few months of furious coding. Professionally designed and implemented algorithms, like Rijndael, SHA and RSA got exactly the kind of attention needed to turn them into strong, efficient cryptosystems and that took lots of time and money. You wanna do it anyway? Fine, but at least let the crypto community peer-review your idea and listen to their criticism.[[/labelnote]]

A problem with encryption is that the encrypted data cannot be changed, otherwise decrypting it will result in garbage. But what if you can make modifications to the encrypted data and when you decrypt, those changes carry over? That is, say Alice wants to know the answer to 2 + 5 but doesn't want Bob to know she's using 2. She encrypts 2 as 5, Bob adds 5 to the encrypted value, and then she decrypts the value to get 7. This is the idea behind homomorphic encryption: allowing people to change the data and keep those changes upon decryption, but not know what the data actually is.

Like encryption in general, homomorphic encryption starts with a key to encrypt and decrypt the data. However, instead of hiding the information by swapping bits around, it encodes the data by using a math function. For example, let's say Alice has an array of numbers: 9, 0, 2, 6, 7, 2, 8, 1, 6, 8. She can apply a simple "add 2" cipher to it to get 11, 2, 4, 8, 9 ,4, 10, 3, 8, 10. Then she asks Bob to add these numbers together. Bob does so and gives Alice the answer "69". Alice can apply the opposite of the "add 2" cipher, achieving the real answer of 49. Of course, this is a highly simplified example; more complicated functions are used in practice. Also, for certain schemes not every math operation can be used on the encrypted data. If that's the case, then the encryption scheme is known as Partial Homomorphic Encryption (PHE). If ''any'' math operation can be done, it's known as Fully Homomorphic Encryption (FHE)

A problem with encryption is that the encrypted data cannot be changed, otherwise decrypting it will result in garbage. But what if you could make modifications on encrypted data and when you decrypt it, you get the modifications? That is, say you encode 2 into 5 and you want someone to add 5 to it. You could make it seem like 5 + 5 = 7. This is the idea of homomorphic encryption: allowing others to modify the data without knowing what the data really contains.

This is where the cryptographic hash function comes into play. A hash function takes the bytes that make up the data, adds them together in a convoluted manner, and spits out a number of fixed size called a digest. That is, for ''any'' input, the function will spit out a value that has the same number of bytes. For a hash function to be suitable for cryptography, it must have a reasonably large digest size. A larger digest size decreases the chances of two inputs producing the same output, called a collision. Another characteristic is that for a small change in input, the function must create an output so that no obvious relationship can be made between the two. Hashing, as it's called, is one-way, hence one-way encryption. That is, theoretically you cannot map a digest back to its original content because a digest has an infinite number of things that could map to it.

So to store the passwords of user accounts, their password is sent through a cryptographic hash function and the result is what's stored in the database. Every time they enter the password, it's run through the same hash function and the output is compared to what's in the database. This way, even if an attacker steals the database, all they get for passwords are random values that can't be used to figure out what the actual password is.

However, the hash function itself is not enough. If you input the same thing in a cryptographic hash function, it'll spit out the same output. To combat this, ''salt'' is added. Salt is a random value that's included with the input to a hash function and is also stored with the user account. [[note]]Storing the salt is not insecure as long as the salt is different for everyone and the size of the salt is prohibitively large for an attacker to try every combination[[/note]] This way, in the password storing database, even if two or more people use the same password, their hashes will be different due to the salt. Running the password through a cryptographic hash function plus salt solves the three issues noted before with encryption:

Like encryption in general, homomorphic encryption starts with a key to encrypt and decrypt the data. However, instead of hiding the information by swapping bits around, it does so by way of putting the information through a complicated math function. This is how it allows encrypted data to be modified. For example, let's say Alice has an array of numbers: 9, 0, 2, 6, 7, 2, 8, 1, 6, 8. She can apply a simple "add 2" cipher to it to get 11, 2, 4, 8, 9 ,4, 10, 3, 8, 10. Then she asks Bob to add these numbers together. Bob does so and gives Alice the answer "69". Alice can apply the opposite of the "add 2" cipher, achiving the real answer of 49. Of course, this is a highly simplified example; more complicated functions are used to encrypt the values. Also, for certain schemes not every math operation can be used on the encrypted data. If that's the case, then the encryption scheme is known as Partial Homomorphic Encryption (PHE). If ''any'' math operation can be done, it's known as Fully Homomorphic Encryption (FHE)