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.