This article is a part of a series on Cryptography. Use the navigation boxes to view the rest of the articles.

We’ve established how Asymmetric encryption makes use of two mathematically linked keys: One referred to as the Public Key, and the other referred to as the Private Key. We’ve also established that what one key encrypts, only the other can decrypt.

These two attributes allow us to perform two separate operations with a Key Pair.

### Asymmetric Encryption

Below is an illustration of Bob (on the right in red) looking to send an encrypted message to Alice (on the left in purple).

Since Bob and Alice are two different entities, they each have their own set of Public and Private Keys. Their public keys are on the inside, available to each other. While their private keys are on the outside, hidden and out of reach.

When Bob has a message he wishes to securely send to Alice, he will use **Alice’s Public Key to Encrypt** the message. Bob will then send the encrypted message to Alice. **Alice will then use her Private Key to Decrypt** the message and extract the original message.

Since Bob encrypted the message with Alice’s **Public** key, he knows that the only possible key that could extract the message is Alice’s **Private** key. And since Alice never shared her key with anyone, Bob knows that only Alice was able to read the message.

Thus, the concept of confidentiality can be provided with an Asymmetric key pair.

### Asymmetric Message Signing

But confidentiality isn’t the only thing you can do with a Public and Private Key. Remember, *either *key can be used for encryption. This fact can be used to give us one additional feature from an asymmetric key pair.

Let us imagine that now Alice wants to send a message to Bob. This time, however, Alice does not care about the confidentiality of her message. Which is to say, she doesn’t care if anyone can read it. But she is very concerned that Bob knows beyond a shadow of a doubt that it was definitely Alice that sent the message.

Alice can use **her own Private Key to encrypt the message**. Which makes it so the only key in the world that can decrypt her message is her Public key — *which she knows Bob (and anyone else) has access to*.

The message is sent to Bob, who then uses **Alice’s Public Key to decrypt the message**. If Bob was able to successfully extract a message, and not a scrambled series of bits, then he can be assured that the message must have been originally encrypted by Alice’s Private Key. And since Alice never shared her Private Key with anyone, Bob can be assured that Alice indeed sent the message.

This process is known as **Message Signing**. It is a creative use of the fact that the keys are mathematically linked, and that what one key encrypts, only the other can decrypt.

### Real World Usage

Now that we have illustrated the basic premise. We can take it a step further and really look at how these concepts are actually used in modern cryptography.

#### Real World Encryption

Earlier, we discussed that Asymmetric encryption is slower and has properties which make it not ideal for bulk encryption. We should instead find a way to use Symmetric encryption, since it is better suited for bulk data encryption. But with Symmetric encryption, we have to deal with the Key Exchange issue.

The solution is to use what is sometimes referred to as **Hybrid encryption**, which **combines the strengths of both Symmetric and Asymmetric encryption**, while avoiding all their weaknesses.

Let’s describe how that works by continuing to use Alice and Bob from above as an example.

Bob starts by randomly generating a Symmetric Secret Key. Then, instead of Bob using Alice’s public key to encrypt the *message* directly, Bob uses Alice’s Public Key to encrypt the Symmetric Secret Key. This encrypted symmetric key is sent across the wire to Alice.

Alice can then use her Private Key to extract the Secret Key that Bob sent. At this point, both parties now have an identical Secret Key that they can use to *Symmetrically* encrypt as much data as they please, in both directions.

In this way, Bob and Alice use Asymmetric Keys to securely exchange a Symmetric Key, which is then used for Symmetric encryption. They are getting the security of Asymmetric encryption, with the speed and efficiency of Symmetric encryption — the best of both worlds.

#### Real World Signatures

Similarly, the Message Signing process is more than simply using the Private Key to encrypt the message. Again, the limitations of Asymmetric encryption would end up imposing a limitation on what sort of data can be signed.

Can you guess what method is employed to reduce the message of variable length to a constant, more manageable representational value?

You guessed it… a Hashing algorithm. Lets talk through it using Bob and Alice.

Alice wants to sign a message to Bob. She runs her message through a Hashing Algorithm, and then encrypts the resulting digest with her own Private Key. The encrypted digest then gets sent to Bob, along with the original message.

Bob then uses Alice’s public key to decrypt the digest he received, then he independently calculates the hash of the original message. Bob then compares the (now decrypted) digest which was sent, and the digest which he calculated.

If they are the same, then Bob knows that Alice indeed must have sent the original message.

Moreover, Bob also knows that the message has not changed since Alice calculated the original digest — the signature had the bonus effect of also ensuring the Integrity of the original message!

### Math is Hard

Most people can wrap their mind around Symmetric encryption fairly easily. Take a starting value, perform some mathematical operation, and you end up with cipher text. To convert it back, you simply perform the operation in reverse.

But Asymmetric encryption is slightly more complicated. Without prior exposure to Asymmetric encryption, its difficult to imagine a mathematical operation that you can perform on a starting value that is *impossible* to reverse. Even if you know the Public Key and the Algorithm used.

To that end, we’ve added an article as an appendix to the Cryptography series which explores the math behind a widely used Asymmetric algorithm in use today.

If math causes your eyes to glaze over, feel free to skip it, so long as you understand the basic concepts described throughout this series. But if you are slightly curious about how an Asymmetric algorithm works, head on over to the post on the RSA algorithm.

In the “Asymmetric Message Signing” section above, it says “If Bob was able to successfully extract a message, and not a scrambled series of bits, then he can be assured that the message must have been originally encrypted by Alice’s Private Key.” What if the message is not meant to be plaintext but binary, ie. a series of bits? How does Bob verify that the series of 1s and 0s was originally encrypted by Alice’s private key?

Hi Sunny. Good Question.

In reality, the original message is not actually encrypted with the Private Key.

The message is sent through a hashing algorithm, and the resulting digest is encrypted with the Private key.

This allows the receiver (Bob, in this case) to decrypt the digest with the Public key, and compare it to a hash he calculates on the received message. If they match, then it proves the message wasn’t changed since Alice sent it, and only Alice could have created the included digest.

More details on this in the real world signatures section.

In the section, “Real world encryption……Bob uses Alice’s Public Key to encrypt the Symmetric Secret Key….”.

Here, Bob has two choices,

Choice 1: use Alice’s public key: This is the choice Bob picked above. Only Alice can decrypt the message, great. But, how can Alice be certain that Bob sent this “symmetric key”. Could be anyone, since Alice’s public key is available.

OR

Choice 2: use Bob’s private key: If Bob uses this choice, anyone online can use Bob’s private key and get access to the symmetric key. But, Alice is 100% certain that Bob sent the message.

A related question is, once Alice receives the encrypted symmetric key. Is it a trial and error to decide if she has to use –

1. her own private key to decrypt

OR

2. Use Bob’s public key to decrypt the message.

How does Alice decide which key to use to decrypt the message? Try 1, next, try the other, next, ….!

Crypto novice questions, showing my ignorance. 🙂

Great series, very helpful. Appreciate the effort.

Thanks.

– m

Great question!

In most “secure” communication protocols, there is a step after the exchange of the keys which validates that the right person has the right keys. For instance, in TLS/SSL, the “Finished” message serves this purpose.

Essentially the way it works is, the “Key Exchange” process outlined above is combined with the “Signatures” process. In simple steps, Bob will encrypt the Symmetric Key with Alice’s Public Key, then “encrypt”

thatwith his Private Key. This means anyone can verify it was definitley sent from Bob, but only Alice can extract the actual Symmetric Key.Glad you enjoyed the series. Good questions!

Thank you for the explanation.

In Asymmetric, both entities must have own private and public key?

Or Bob having private and secret but Alias has only one key (Private or Public)

Just want to know, Can Public key encrypt and decrypt data?

The keys exist within a key pair. Sharing one set across multiple people would defeat the primary benefit an asymmetric key pair — the fact that you never have to share the key. If you have to share the key and you can do so securely, then Symmetric encryption will provide more security (per bit of key size) and faster speeds.

So yes, a key pair must be owned by a single entity.

Now, if Alice has a public and private key, Bob can use Alice’s public key to securely exchange a symmetric key. So it absolutely is possible for there to be only a single party with a Public/Private Key and for secure communication to exist. Notice in the “Real World Usage” section, Bob’s public and private key are never used, only Alice’s. In fact, this is what happens with TLS/SSL when you browse to a website, your browser doesn’t have a public/private key, but the web server does.