Humans have always been concerned when it comes to trusting others. One of the most troubling trust concern for humans is the secure and uninterrupted passing of messages from one person to another. "What if my message was intercepted and read by someone", "What if my message was intercepted and modified by someone" are just a couple of questions that come to mind.

We have been coming up with ways to secure our messages from ancient times and we have finally achieved a high standard of security for sending messages. This high standard of security doesn't seem hackable in the near future. And thus this article focuses on explaining this standard which we call **Modern cryptography** or **Public key cryptography**

In most of the examples you will come across while studying cryptography, you will find these 2 names "Alice" and "Bob". Alice and Bob are fictional characters who are often used as placeholders for real people in discussions and examples about cryptography. Alice and Bob are 2 people trying to securely communicate with each other, while let's say another person "Darth" is trying to intercept and read/modify their communication. We will be using these 3 characters, Alice, Bob and Darth for the examples in this article as well.

# What is cryptography?

Cryptography is the study of techniques for secure communication. These techniques are based on mathematical theorems and proof, but don't worry you don't need to have a background in maths at all for this article and nor am I going to be explaining those boring theorems.

In cryptography, a **key** is a piece of information (a number or a string) used for scrambling data so that it appears random

Modern cryptography tries to solve 2 problems:

- Making sure that the message isn't read by someone in the middle. Let's call this "someone", the middleman
- Making sure that the message isn't modified by a middleman.

## Basic cryptography, a brief introduction

The most basic and one of the oldest forms of cryptography was the *Caesar Cipher,* named due to being used by the Roman ruler, Julius Caesar to communicate confidential messages to his generals.

It is a type of substitution cipher (think of a cipher as a crypto algorithm) in which each letter in the plaintext is 'shifted' a certain number of places down the alphabet. This *certain number* is known as the *key.* For example, with a key of 1, A would be replaced by B, B would become C, M would become N, Z would become A and so on.

If the key is 1, the message `abc`

would be encrypted to `bcd`

For the message `retreat`

and for the key 1, the encrypted message would be `sfusfbu`

.

For the key 2 the encrypted message for `retreat`

would be `tgvtgcv`

and so on.

You can play around with the Caesar cipher at this link.

Obviously, this method of cryptography is not the most secure way of communication.

### Cons of the Caesar Cipher

- You will need to share the key between your "generals" securely without anyone else knowing about that key because anyone with that key and an understanding of the cipher can easily decrypt the message.
- A key can only be a number from 1 to 25 since there are only 26 letters in the alphabet. If you think about it a key of 27 is nothing but a key of 1, a key of 28 is actually a key of 2 and so on. Thus a hacker can easily decrypt the message with a combination of guessing, luck and trial and error.

Below is an image of the Caesar cipher in action, with a key of *2*

The Caesar cipher is a form of symmetric key cryptography.

In symmetric key cryptography, the same key is used to encrypt and decrypt a message. This key is kept a secret. By using symmetric key cryptography algorithms, data is converted to a form that cannot be understood by anyone who does not possess the secret key to decrypt it.

New methods of symmetric encryption have been discovered which are far more secure than the Caesar cipher **but the problem of safeguarding the common key still remains.**

Note that Caesar Cipher can only use numbers as keys but modern symmetric cryptographic techniques can use any string of characters as a key. This immediately makes it more secure than the Caesar Cipher since we can chose a key from an infinite range of keys, instead of just 26 numbers. (Infinite because a key doesn't have to be of a fixed length)

The following can be used as keys

- dhdfhf
- djf776f
- 5757
- cxjd^&

A simple analogy of symmetric cryptography

Imagine a trunk with a lock that Bob and Alice, use to ship documents back and forth. A typical lock has only two states: locked and unlocked. Anyone with a copy of the key can unlock the trunk if it's locked, and vice versa. When Bob locks the trunk and sends it to Alice, he knows that Alice can use her copy of the key to unlock the trunk. This is essentially how what's known as symmetric cryptography works: one secret key is used for both encrypting and decrypting, and both sides of a conversation use the same key.

Example taken from: https://www.cloudflare.com/en-gb/learning/ssl/how-does-public-key-encryption-work/

You can play around with modern symmetric key cryptography using this link.

Here's how a conversation between Alice and Bob would work with **symmetric** key cryptography

- Alice and Bob decide upon a key beforehand. Let's say the key is
`test123`

. They keep this key to themselves - Alice wants to send a message
`Hi`

to Bob - Alice encrypts the message
`Hi`

with the key`test123`

which gives an output of`my+looOXzJkrnYs/RCK9nA==`

- Alice send the encrypted message
`my+looOXzJkrnYs/RCK9nA==`

to Bob. - Bob uses the key
`test123`

to decrypt the encrypted message`my+looOXzJkrnYs/RCK9nA==`

- The decryption gives an output of
`Hi`

This way we make sure that the conversation between Alice and Bob is **mildly** private.

Why **mildly**:

- If Alice and Bob can't meet physically they would have to share the key
`test123`

to each other, over the internet, which again can be intercepted by a middleman. - This makes symmetric key cryptography not really helpful for private conversations.

Modern cryptography solves this problem by using **asymmetric** encryption/decryption

# Asymmetric key cryptography or Public Key Cryptography

In asymmetric key cryptography, one key is used to encrypt a message while a different key is used to decrypt that message. How that works: You will have to look at something called the `Extended Euclidian Algorithm`

, which I won't be covering in this article.

In asymmetric key cryptography, each participant in the conversation has a pair of keys: public key and a private key.

And as they sound a public key is something which you share with others freely without fear of your conversation being hacked. While a private key is something you keep to yourself. You can compare public key/private key to username/password.

A public key and private key are 2 really large numbers (about a 100 digits) mathematically related to each other. But it's really really hard to derive the private key from the public key and vice-versa.

It will take hundreds of years to derive a private key from a public key even with many supercomputers. But it's not hard to create a pair of public and private keys and that's the beauty of it.

Here's a sample table of the pair of keys (public and private) which Bob and Alice have

According to the above table, Alice's public key is `public_key1`

which we will abbreviate to `PB1`

and her private key is `private_key1`

which we will abbreviate to `PV1`

Whereas Bob's public key is `public_key2`

which we will abbreviate to `PB2`

and his private key is `private_key2`

which we will abbreviate to `PV2`

**A message encrypted with a public key can only be decrypted with the corresponding private key and vice versa.**

Example: only Bob's private key can decrypt a message encrypted with Bob's public key. Only Alice's private key can decrypt a message encrypted with Alice's public key.

This opens up a whole new world in software. Let's see how.

Here's how a conversation between Alice and Bob would go with **asymmetric** key cryptography

- Alice and Bob share their respective public keys,
`PB1`

and`PB2`

with each other. This is usually done with a common database. - Alice wants to send a message
`Hi`

to Bob. - Alice encrypts the message
`Hi`

with Bob's**public**key`PB2`

- Alice sends the encrypted message to Bob
- Since only Bob's
**private**key`PV2`

can decrypt the encrypted message as specified earlier, Alice can be sure that no one but Bob can read the message - Bob receives the encrypted message
- He decrypts it with his
**private**key`PV2`

and reads it.

Great! So one problem solved. But a middleman can still intercept the message, write a new one on top of it, encrypt the new message with Bob's public key `PB2`

and pass it on to Bob. This reminds us of the other problem we are supposed to solve. How does Bob know that the message is really from Alice.

Now remember, `A message encrypted with a public key can only be decrypted with the corresponding private key and vice versa.`

Here's what Alice can do now so that Bob can know if a message is really from Alice:

- Alice can encrypt the message with her private key.
`PV1`

- So the message can only be decrypted by using Alice's public key
`PB1`

. - Alice sends the encrypted message to Bob
- Bob tries to decrypt the message with Alice's public key
`PB1`

- If the message is successfully decrypted, then Bob knows the message was encrypted by Alice's private key which implies that the message was really sent by Alice since only Alice knows her private key.
- If the message can't be successfully decrypted then Bob knows that the message is not from Alice

But we are faced with the first problem again. Since Alice's public key is known to everyone, anyone can decrypt the message and see the content inside. So it's a loop of problems. We either make sure that the message isn't read by anyone or we make sure that the message isn't altered by anyone.

Fortunately there is a work around for this

- Alice can first encrypt a message with Bob's public key
`PB2`

- Alice can then encrypt the
**encrypted**message with her private key.`PV1`

. This step is known as**signing**the message. - This way even if anyone tries to decrypt the message with Alice's public key, all they will see is another encrypted message which only Bob can decrypt using his private key.
- Alice then sends the message to Bob
- Bob will first decrypt the encrypted message with Alice's public key
`PB1`

which will return another encrypted message - Bob will then decrypt this "another' encrypted message with his private key
`PV2`

and read the message

This way we can be sure that no one can listen in on the conversation and no one can alter the conversation. Note that this is only applicable when the private key is kept secret by the person it belongs to.

This is how modern cryptography works and this is the core which powers the revolutionary tech like blockchain and cryptocurrency. I hope this article was helpful to you. Stay tuned for more articles in the **Blockchain for the average web developer** series.

## Top comments (0)