Why asymmetric encryption?

What is encryption?

Say Raj needs to send a message to Priya. Easy right? But, there is one catch: whatever message Raj sends to Priya will be visible to the whole world. Argh!

Raj comes up with an idea: Raj will not send the actual message to Priya. Instead, he will transform it to another form which will appear nonsense to the whole world, but Priya will be able to transform it back to the real message.

E.g.:

Say the actual message is: Hello

Raj applies some mathematical operation to "Hello" and it becomes: abc123 (aka encryption). Which is total nonsense to everyone.

But Priya knows about the reverse mathetimatical operation which will transform abc123 to Hello (aka decryption).

Great! Problem solved!

Types of encryption

Symmetric encryption: There is one key used to encrypt the message. The same key can be used to decrypt the message. Example algorithms: AES, DES, ...
Asymmetric encryption: One key is used to encrypt the message. But a different key is used to decrypt the message. The same key cannot be used to perform both encryption and decryption. Some use cases are illustrated below. Example algorithms: RSA, ECDSA, ECDH, ...

Use case 1

Here is a conversation between Raj and Priya over the internet on an un-secure chatting platform, i.e.: all these chats are visible to everyone.

Raj: Hello Priya, here is our revenue forecast for this year: jskdfn. Its confidential, hence encrypted with AES Key: A!123. You can use the same to decode it.
[Raj used symmetric encryption to encrypt the confidential data and also shared the key used to encrypt. NOTE: the same key can be used to decrypt it]
Priya: Raj, what did you do! Now everybody knows the secret key and they can use it decrypt the revenue forecast! The whole world knows about it now.

What went wrong?

Raj encrypted the confidential information with a symmetric key. All good so far. But Raj shared the symmetric key with Priya over an unsecured channel, which is a blunder, because once people get to know the symmetric key, they can decrypt the message.

Alternate scenario

Raj: Hello Priya, can you please share your PUBLIC key [more on PUBLIC and PRIVATE keys later]?
Priya: Here it is: pubkey001.
Raj: Here is our revenue forecast encrypted with your Public Key: ueihwf.
Priya: Thanks, I will use my PRIVATE key to decrypt the message.

What happened here?

With asymmetric encryption, we get a pair of keys:

A Private Key: As the name suggests its supposed to remain PRIVATE always. It shouldn't be shared with anyone.
A Public Key: Its supposed to be public - shared with everyone freely.

If we encrypt a message using a Public Key, it can be decrypted ONLY with the matching Private Key (and not with the Public Key). Similarly if we encrypt a message with a Private Key, it can be decrypted ONLY with the matching Public Key.

In the alternate scenario illustrated above, Priya shared her PUBLIC key with Raj. Raj encrypted the confidential message with the PUBLIC key and shared with Priya. Now even if anybody else gets to know about the Public Key and encrypted message, they WON'T be able to decrypt it, as it can be decrypted ONLY with the PRIVATE Key. And only Priya has the Private key which she hasn't shared with anyone.

NOTE: It is not always possible to encrypt an entire message with an asymmetric key (encrypting long messages with asymmetric keys will be quite slow and expensive). A general practise is to GENERATE a random symmetric key, and encrypt the symmetric key alone with the asymmetric key. And, the actual message content is encrypted with the symmetric key. So we get a payload of:

Symmetric key encrypted with asymmetric key
Message contents encrypted with symmetric key

The recipient can:

Retrieve the symmetric key by decrypting it with the matching asymmetric key pair
Decrypt the actual message contents with the symmetric key obtained above

Use case 2

Sam: Hi Priya, Raj has left this message for you: "Sell all my shares today".
Priya: Hello Sam. How do I know that it is really Raj who left that message? Can you please ask Raj to digitally sign this message with his PRIVATE key?
Sam: Sure, Raj has sent the signature as well: mzakld
Priya: Cool, since I already have Raj's PUBLIC key, I can now verify whether it was really Raj who sent the message.

What is this digital signature?

In the previous use case, we saw that the message was encrypted with the Public Key. Here it's kinda reverse. This is how Raj signs the message:

He generates a Hash of the message.
And then encrypts the Hash with his PRIVATE key, which becomes the signature of the message

How does Priya verify the signature?

Priya should already be knowing Raj's PUBLIC key (Remember, PUBLIC keys are meant to be public and known by everyone)
She decrypts the signature (mzakld) using Raj's PUBLIC key. Lets call it - HASH_VALUE_1
And then independently generates a hash of the message contents ("Sell all my shares today"). Lets call it - HASH_VALUE_2
She verifies whether HASH_VALUE_1 is equal to HASH_VALUE_2.
Anybody other than Raj will not have Raj's PRIVATE key. If any other Private key is used to sign the message, then when the signature is decrypted using Raj's PUBLIC key, it won't match with the hash of the message contents. Thus Priya will know that the message was not from Raj.

NOTES:

If the message is being sent over an un-secure channel, then the message (and optionally its signature as well) can be encrypted using the approach described in Use case 1.
Depending on the use case, additional attributes (like UUID, timestamp) maybe included in the message to ensure every message is unique. This will help in preventing replay attacks.
In all cases, the Private Key always remains private and is never ever shared with anyone.

Use case 3

Assume that Priya has received Raj's public key prior to this conversation and she is certain that the Public key really belongs to Raj.

Below is a conversation taking place of an un-secure hackable channel.

Raj: Hi Priya
Priya: Hello Raj. I don't know for sure whether you are really Raj or not. To prove that you are indeed Raj, I challenge you to encrypt this random text that I just generated: njsdks using your PRIVATE key.
Raj: Sure, here it is: zsdeaf.
Priya: Cool, now I can decrypt zsdeaf using Raj's PUBLIC key and verify whether it matches the original challenge text (njsdks) that I had generated.
Priya: I have GENERATED a random symmetric key and have encrypted it with your PUBLIC key: opwefi. Going forward lets encrypt all our messages with this symmetric key.
Raj: Nice. I can decrypt the symmetric key (opwefi) using my PRIVATE key, and use the decrypted symmetric key to encrypt / decrypt further communications with Priya.

What is happening?

Priya challenged Raj to encrypt a random text that Priya had generated with Raj's Private Key.
Since only Raj has access to his own Private Key, only Raj should be able to encrypt the challenge text with his Private key.
And the encrypted challenge text can only be decrypted with Raj's Public Key which is known to Priya (and maybe everybody else).
So Priya is able to verify whether Raj's Private Key was indeed used to encrypt the challenge text, which will prove that the person she is talking to has access to Raj's Private Key, which can only be Raj himself (of course unless Raj's private key has been stolen / leaked :-p).
Next, Priya generated a random symmetric key, encrypted it with Raj's Public Key and shared it.
Only Raj will be able to decrypt it as Raj alone has access to Raj's Private Key.
Going forward they can use the symmetric key to encrypt all messages as it will be faster and less expensive.

Above steps are a very simplified version of SSL/TLS handshake.

Optionally, Raj can also challenge Priya to prove herself. This is somewhat similar to mutual TLS, however such mutual TLS can happen only if both the entities are known to each other.

The three use cases mentioned above are fundamental building blocks of the https protocol and blockchain (blockchain is so much more though).

Hope you liked the reading. Please share your feedback as comments or DM / connect with me over LinkedIn!