Encryption is the idea of encoding, manipulating, or otherwise obfuscating data to the point where it is unreadable or unintelligible to a 3rd-party.
How do you encrypt data? Well, there are several overall types of encryption – and then there are several different “products” one can use to actually use the various types of encryption. In this article, I will try to cover all the major pieces.
What kind of algorithms are there?
There are 3 basic kinds of encryption algorithms:
- Symmetric encryption
- Message digest/one-way-hash
- Asymmetric encryption
This is the kind of encryption that everyone thinks of. This is where you have some data, and you have a “secret key”. You encrypt the data with the secret key – and the only thing in the world that can decrypt it, is that same secret key.
Within this style of algorithm, there are many implementations from: not-secure, to very secure. However, despite this being a common and fast way to encrypt data, there is a fundamental flaw – the key.
Imagine you and I are encrypting messages. We decide on a key that we both will use. I wrote the passphrase for the key on a Post-It note and it’s stuck to my laptop. We use this encryption key for years, and everything is and has been secure.
Now imagine my laptop is stolen, and the attacker now has the key. Now, every single thing that has ever been encrypted with that key, is now compromised. So, even though the data has been secured for years, now that the key has been compromised, so has ALL of the data that has been encrypted with it.
Understanding this, there are other ways you can securely use this type of encryption. If you could somehow keep the the intial “key exchange” between the parties safe, that would be good. Also, if you make it so the key is strong enough where it will take longer break the encryption – than the value of the data, that is also good. For example, if you are creating a browser session – and if that session will expire in :20 minutes; and meanwhile it takes 2 weeks to break that encryption, then that is considered OK. Because, even if you break the encryption, the data that you find no longer has value.
Examples of this type of algorithm include:
This is a special kind of encryption that has a few, very specific uses. This is a one-way encryption algorithm; meaning, you take some data and a “key” – and run it through this algorithm and it generates a unique string (a.k.a. “hash”, or “message digest”).
It’s almost mathematically impossible to reverse engineer the original data, using the hash. Also, even if you have the key, you can’t “unencrypt” using this sort of algorithm.
What is the point then? There are two main ways this sort of algorithm is used: 1) digital signatures and 2) storing user passwords.
One thing to keep in mind is that regardless of how big or small the data is that is passed in, the resulting length of the hash is always the same. Each algorithm has a different length output. Why is this useful? Well, if anyone one character changes in your source data, it results in a wildly-different hash.
Scenario #1 – Signatures: I have a document that I don’t want people to secretly change (perhaps a legal document). I run the document through my SHA1 algorithm, passing it the entire document – and then the “salt string” of “12934fwde0sdnh34ijberv0sd9fyu”.
I send you the document, and the resultant hash, for example: “de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3”. Now, I tell you: “run this through SHA1 and pass it the pre-arranged salt string, and you should get the same hash”. If you do, and you get the same result, then you know the document was not tampered with. If you get a different hash, that means that something changed in the document – it could be changing the case of a letter, or someone could’ve removed a paragraph. Either way, you know the “signature” is not valid, so you know to not trust the contents.
Scenario #2 – Passwords: Another common use of this type of algorithm is for storing passwords. Imagine you have a website or application where you need to store your users’ usernames and passwords. You certainly don’t want to store them in clear-text. If your website or database are compromised, you will have serious problems. You could encrypt all the passwords with one key – but as mentioned above, if the key is compromised, so are all the passwords.
A better way to handle this, is to generate a hash based off a users typed password. This is good because NOT EVEN I know what the users password is! Imagine this scenario – a user creates an account and types a password of “Apple123!”. Now, I run that through my SHA1 algorithm with some salt string. I take the result, for example “de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3” and store that in my database in the “password” column.
Later, when the user comes back (or when an attacker arrives), they put in a password. We take what they gave us, hash it with our salt string and look for a match in the database. If the string they typed generates the same hash – then we know the password is good. If they mistyped even a single letter, the hash will be completely different, which means the password will not match what is in the database.
Using this approach makes it safer for everyone involved. Your organization doesn’t know the password – and therefore can’t be compromised, and it’s safer for the user. Many users use the same password on multiple sites. If the password was compromised on THIS system, then that same password might work on other systems including bank and credit websites.
Examples of this type of algorithm include:
Public Key Infrastructure (PKI):