History UsefulNotes / Encryption

25th Feb '18 4:37:07 PM xenol
Is there an issue? Send a Message


* You need a key to encrypt something, and that key must be stored somewhere the database can access it.
* If someone dumps the database of the encrypted passwords, you can easily multiple people have used the same password.

to:

* You need a key to encrypt something, and that key must be stored somewhere in a place where the database can access it.
* If someone dumps the database of the encrypted passwords, you can easily see multiple people have used the same password.
25th Feb '18 4:36:33 PM xenol
Is there an issue? Send a Message


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 the problem is the key must lie somewhere else accessible to the database to decrypt it. Plus, on top of that, if different people use the same password (and there are lot of common passwords), it's obvious.

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. As an example, the [=MD5=] hash function always spits out a 128-bit value, regardless of how much data was put into it. While ideally a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, [=MD5=] is not considered useful for cryptography, but other hash functions, like [=SHA2=], are. The main difference between a normal hash function and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and output a larger fixed value such that it makes reversing the hash even harder.

to:

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 the problem is the this presents several issues:
* You need a key to encrypt something, and that
key must lie be stored somewhere else accessible to the database to decrypt it. Plus, on top can access it.
* If someone dumps the database
of that, if different the encrypted passwords, you can easily multiple people use have used the same password (and there are lot password.
* Most encryption methods output varying sizes based on the input. AES-128 for example, outputs 16 bytes for every set
of common passwords), it's obvious.

16 characters you input. An attacker could deduce how many characters the plaintext has.

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. As an example, size called a digest. That is, for ''any'' input, the [=MD5=] hash function always spits will spit out a 128-bit value, regardless value that has the same number of how much data was put into it. While ideally bytes. For a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, [=MD5=] is not considered useful to be suitable for cryptography, but other hash functions, like [=SHA2=], are. The main difference between it must have a normal hash 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 and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and create an output a larger fixed value such so that it makes reversing no obvious relationship can be made between the hash even harder.
two.



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

to:

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. 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.
salt. Running the password through a cryptographic hash function plus salt solves the three issues noted before with encryption:
* No key is necessary.
* If someone dumps the database of hashed passwords, you can't tell if people used the same password.
* The outputs are of same size, so you can't tell if someone used a 6-letter password or a 100-letter one.
23rd Jan '18 4:38:21 PM xenol
Is there an issue? Send a Message


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. As an example, the [=MD5=] hash function always spits out a 128-bit value, regardless of how much data was put into it. While ideally a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, [=MD5=] is not considered useful for cryptography, but other hash functions, like SHA2, are. The main difference between a normal hash function and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and output a larger fixed value such that it makes reversing the hash even harder.

to:

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. As an example, the [=MD5=] hash function always spits out a 128-bit value, regardless of how much data was put into it. While ideally a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, [=MD5=] is not considered useful for cryptography, but other hash functions, like SHA2, [=SHA2=], are. The main difference between a normal hash function and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and output a larger fixed value such that it makes reversing the hash even harder.


Added DiffLines:

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.
23rd Jan '18 4:29:57 PM xenol
Is there an issue? Send a Message





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. As an example, the MD5 hash function always spits out a 128-bit value, regardless of how much data was put into it. While ideally a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, MD5 is not considered useful for cryptography, but other hash functions, like SHA2, are. The main difference between a normal hash function and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and output a larger fixed value such that it makes reversing the hash even harder.

to:

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. As an example, the MD5 [=MD5=] hash function always spits out a 128-bit value, regardless of how much data was put into it. While ideally a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, MD5 [=MD5=] is not considered useful for cryptography, but other hash functions, like SHA2, are. The main difference between a normal hash function and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and output a larger fixed value such that it makes reversing the hash even harder.
23rd Jan '18 4:29:33 PM xenol
Is there an issue? Send a Message

Added DiffLines:

'''Cryptographic hash functions'''
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 the problem is the key must lie somewhere else accessible to the database to decrypt it. Plus, on top of that, if different people use the same password (and there are lot of common passwords), it's obvious.

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. As an example, the MD5 hash function always spits out a 128-bit value, regardless of how much data was put into it. While ideally a hash function will produce a unique number for any input, since the output is of fixed size, eventually you'll find two inputs that generate the same output (a collision). As a side note though, MD5 is not considered useful for cryptography, but other hash functions, like SHA2, are. The main difference between a normal hash function and cryptographic one is that a cryptographic one must be more chaotic (that is, small changes produces huge differences) and output a larger fixed value such that it makes reversing the hash even harder.

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. 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.
3rd Dec '17 6:08:51 AM KakuradyDrakenar
Is there an issue? Send a Message


A novel method based on one-time pads 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 encrypts the response with the nonce and sends it over to Alice. Alice encrypts 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.

However, there's a trick to this. Eve, an eavesdropper, can pretend to be Alice and ask Bob, Charlie, and others using the same nonce. From their responses, Eve can try figure out their passwords just by brute forcing, or using a dictionary of known passwords. To combat this, Bob can also send a nonce with the encrypted response (encrypted with everything), which Alice can use on her end to see if Bob is legitimate. Since Alice and Bob are both using nonces, Eve will have a harder time figuring out the password.

to:

A novel method based on 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 encrypts the response with the nonce and sends it over to Alice. Alice encrypts 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.

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 and ask Bob, Charlie, and others using the same nonce. From their responses, Eve can try figure out their passwords just by brute forcing, or using a dictionary of known passwords. To combat this, Bob can also send a nonce with the encrypted response (encrypted with everything), both nonces), which Alice can use on her end to see if Bob is legitimate. Since Alice and Bob are both using nonces, Eve will have a harder time figuring out the password.
5th Feb '17 8:35:56 AM SteveMB
Is there an issue? Send a Message


What it comes down to is that information is scrambled and that some other person can only unscramble it if he/she knows the key used to scramble it.
Cracking the encryption is figuring out how the information was scrambled. Encryption can be done both by hand and with a computer. Note that doing encryption by hand has some limitations, it is impossible to encrypt large amounts of information due to the time it would take and one could not use every encryption, because some calculations might be too difficult to do by hand.

to:

What it comes down to is that information is scrambled and that some other person can only unscramble it if he/she knows the key used to scramble it.
it. Cracking the encryption is figuring out how the information was scrambled. Encryption can be done both by hand and with a computer. Note that doing encryption by hand has some limitations, it is impossible to encrypt large amounts of information due to the time it would take and one could not use every encryption, because some calculations might be too difficult to do by hand.



''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 Ceasar 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.

to:

''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 Ceasar 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.


Added DiffLines:

See HollywoodEncryption for the usual treatment of cryptography in fiction (which generally involves a lot less detailed analysis and a lot more {{technobabble}}).
17th Jun '16 3:54:22 PM Doug86
Is there an issue? Send a Message


''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 Ceasar 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 WorldWarII) were required to encrypt and decrypt messages with reasonable speed and accuracy.

to:

''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 Ceasar 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 WorldWarII) UsefulNotes/WorldWarII) were required to encrypt and decrypt messages with reasonable speed and accuracy.
30th May '16 8:03:52 AM shermanramni
Is there an issue? Send a Message


* Use good passwords. Single words that can be [[ThePasswordIsAlwaysSwordfish easily guessed]] will easily fold under a dictionary attack, and short passwords are relatively easy to brute-force. There are lots of resources regarding strong password generation on the web.
* Keep the keys secret! This is pretty obvious, if someone knows the key, your encryption is ''fucked''.
* Choose the algorithm carefully! Don't use any algorithm that has been cracked (such as the Enigma)! And 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.
* Be weary of tells, habits, and other repeated phrases you use. What allowed code breakers to defeat Enigma (among other things) was that the German military always sent the same type of message at specific times and ended each message the same.

to:

* Use good passwords. Single words that can be [[ThePasswordIsAlwaysSwordfish easily guessed]] will easily fold under a dictionary attack, and short passwords are relatively easy to brute-force. There are lots of resources regarding strong password generation on the web.
web.[[labelnote:Why?]]A strong password is a password that cannot be easily guessed, because that forces the attacker to run a whole brute-force attack, and in a properly designed and implemented cryptosystem, that can be completely unfeasible. Check [[http://archive.is/JFopd here]] for an analysis of brute-forcing AES.[[/labelnote]]
* Keep the keys secret! This is pretty obvious, if someone knows the key, your encryption is ''fucked''.
''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]]
* Choose the algorithm carefully! Don't use any algorithm that has been cracked (such as the Enigma)! And 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.
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]]
* Be weary of tells, habits, and other repeated phrases you use. What allowed code breakers to defeat Enigma (among other things) was that the German military always sent the same type of message at specific times and ended each message the same.
same.[[labelnote:Why?]]Routine is the bane of security, and a good social engineer can see the patterns in your thought process that allow them to crack your passwords. Or simply deceiving you into giving them away. In the other side, a good cryptosystem is one where the ciphertext is indistinguishable from a random output (meaning, if we simply generate a random stream of characters and put it besides a ciphertext, no one can tell you which is which). If a ciphertext has a noticeable pattern, an attacker can deduce things about the cryptosystem and can use those things as attack vectors (example: there was a cryptosystem that had the annoying habit of making the first bit of every encryption block 0, and that was not a concern until someone noticed that it effectively reduced the message space by half, making brute-force feasible.)[[/labelnote]]
1st Feb '16 8:31:33 PM xenol
Is there an issue? Send a Message


A novel method based on one-time pads is the cryptographic nonce ('''N'''umber used '''once'''). This is often used in challenge-response type authentication. In this, the Alice gives the Bob a nonce and asks for a password. The password is encrypted with that and sent back. Alice then does the same thing on her end and if the outputs match, she knows Bob is legitimate. This is to prevent an eavesdropper from using Bob's response, even though they don't know Bob's password.

However, the eavesdropper 'Eve' can pretend to be Alice and ask Bob, Charlie, and others and build tables to find out their passwords. To circumvent that, Bob can send his own nonce, encrypt the password with both his nonce and the one given to him, and send that. Since Bob is using a random value with every response, it makes it harder for Eve to figure out what the password is.

to:

A novel method based on one-time pads is the cryptographic nonce ('''N'''umber used '''once'''). This is often used in challenge-response type authentication. In With this, the Alice gives the Bob a nonce and asks Bob for a password. The Bob encrypts the response with the nonce and sends it over to Alice. Alice encrypts the password is encrypted with that and sent back. Alice then does the same thing on her end nonce generated and if the outputs match, it matches Bob's response, then she knows it's Bob. Every time Alice asks for a password, she gives Bob is legitimate. a new nonce. This is to prevent an eavesdropper someone from using Bob's response, even though they don't know Bob's password.

old responses.

However, the eavesdropper 'Eve' there's a trick to this. Eve, an eavesdropper, can pretend to be Alice and ask Bob, Charlie, and others and build tables to find using the same nonce. From their responses, Eve can try figure out their passwords just by brute forcing, or using a dictionary of known passwords. To circumvent that, combat this, Bob can also send his own nonce, encrypt the password with both his a nonce and with the one given encrypted response (encrypted with everything), which Alice can use on her end to him, and send that. Since see if Bob is legitimate. Since Alice and Bob are both using nonces, Eve will have a random value with every response, it makes it harder for Eve to figure time figuring out what the password is.
password.
This list shows the last 10 events of 52. Show all.
http://tvtropes.org/pmwiki/article_history.php?article=UsefulNotes.Encryption