Backend Engineering 4: Symmetric & Asymmetric Encryption
Backend Engineering 4: Symmetric & Asymmetric Encryption
The security of the data is one of the most concerns in development. You definitely don’t want to expose users’ sensitive data in your database. One of the most common solutions for it is to encrypt data and decrypt it when needed. Today we will talk about Encryption.
Encryption is a process of encoding the data to another form that can’t be read unauthorized. The encryption schema usually uses a key generated by an algorithm.
Note that each time we encrypt the data, the results are not the same. It’s a significant difference between encryption and hashing.
There are 2 types of encryption schemas: Symmetric Encryption and Asymmetric Encryption.
With symmetric encryption, the keys used to encrypt and decrypt data are the same (or can be transformed from one to another in some way)
For example, we have a group chat and we want that only people in that group can read the message. So we can generate a key for that group called the roomKey each time a person sends a message, he/she will encrypt the message with the roomKey, and other people in that group use the roomKey to decrypt the message.
Pros:
- It’s faster than Asymmetric Encryption
- Easy to use
- Efficient for large data
Cons:
- You have to make sure to store and send the key securely
- The reason for these cons is simple, by using the same key to encrypt and decrypt, we get the risk of losing the key to attackers, if attackers can get the key, they can easily decrypt our encrypted data.
Some famous symmetric-key algorithms:
- AES
- DES
- Twofish
- Serpent
- ...
Because of the drawback with Symmetric Encryption, Asymmetric Encryption was invented (it’s also called Public key encryption). This schema uses 2 keys: a public key and a private key. The public key will be used to encrypt the data and the private key will be used to decrypt the data
Let’s see an example of this:
We have 2 friends A and B. Each has its own private and public key. The public key will be exchanged between A and B. So A knows B public key and the same with B. Each time A wants to send some data to B. A will encrypt the data with B’s public key, if B wants to decrypt the data, B must use his/her private key associated with the public key he/she sent to A. This makes Asymmetric Encryption more secure. Because if an attacker gets the public key and the data on the way the data is sent to B, he/she can’t do anything with that data, knowing the public key is not enough to decrypt the data.
Pros:
- The public key can be shared
- Design for small data
Cons:
- Slow
- Inefficient for large data
- Harder to implement
👉 I did some research but haven’t found any “easy to understand” reason for those cons. A high-level reason for the question “why asymmetric encryption is slow” is that it has to do a more complex process to encrypt and decrypt data. While with “inefficient for large data”, the reason is that asymmetric encryption adds some data to initial data which increases the size of initial data.
I might go back to update this if I find out any better explanation for those cons.
Some famous algorithms for asymmetric encryption:
- RSA
- Diffie-Hellman
- DSA
- ...
The given example above is just a simple idea of asymmetric encryption. The point here is about private and public keys. The public is shared and used to encrypt the data while the private key is kept private and only used to decrypt. In real life, we use different algorithms to do some “transform" with the public key and private key to produce a common key. and this common key will be used as a shared key in symmetric encryption to encrypt and decrypt data. The difference here is that the common key is calculated independently from both sides and is not shared anywhere. Let me do an example with Diffie-Hellman. it's a simpler version of what really happens, so if you want to read more about it. Go here
- Firstly, let's assume that we have 2 friends: Bob and Alice
- Bob has his private key a
- Alice has her private key b
- They all agree to have the same public key g
- Now Bob do some transform with a and g to produce a new value ag
- Alice does the same thing with b and g, the result is bg
- Bob and Alice exchange ag and bg
- So now Bob has bg from Alice, Alice has ag from Bob
- Finally, Bob do some transformation to produce the final common key bga
- Alice do the same and get the final common key agb
- it's proven that agb and bga are the same. So now that final common key will be like the shared key in symmetric encryption. Bob will encrypt data with a common key and Alice will use that key to decrypt the data. The most important thing to notice here is that the final common key is calculated independently from both sides and not be shared to the public, (only the recipient used to produce the common key are shared, and it's really really really hard to reproduce the common key from those recipients)
Okay, so that's it for today. See you next time. Don't forget to share if it's useful for you. Thank you and bye bye.