How Public Private Key Pairs Work in Cryptography: 5 Common Examples
4 votes, average: 5.00 out of 54 votes, average: 5.00 out of 54 votes, average: 5.00 out of 54 votes, average: 5.00 out of 54 votes, average: 5.00 out of 5 (4 votes, average: 5.00 out of 5, rated)
Loading...

How Public Private Key Pairs Work in Cryptography: 5 Common Examples

Step-by-step guides (with illustrations) showing how cryptographic key pairs work in five different public key infrastructure (PKI) scenarios.

We know private-public key pairs are used in a multitude of ways (encryption, authentication, digital signatures, etc.) within an IT environment. But the ways they’re used differ dramatically for each use case. This may leave you wondering: how exactly does it all work “under the hood?”

If you’ve ever wanted to know the specifics of each use case in how they’re used, here’s an overview of the five different use cases.

Let’s hash it out.

Public Keys Encrypt and Private Keys Decrypt — Right?

The short answer? Not always. Yes, in most use cases, a public key is used to encrypt data while its corresponding private key is used to decrypt secrets. However, there are exceptions when it comes to certain processes. We’ll break all of this down for you in the following sections, taking a look at five very common use cases:

  • SSL/TLS (HTTPS)
  • Code Signing
  • Document Signing
  • Email Signing
  • Email Encryption

1. How a Public-Private Key Pair Works During an SSL/TLS Connection

When you visit a secure website using HTTPS, every connection starts with a process called a TLS handshake. This process involves using public key encryption (i.e., asymmetric encryption) to exchange sensitive information before switching to symmetric encryption for the rest of the session.

Why bother switching? Because symmetric encryption requires less computational power than public key encryption does. Even though we’re talking about minuscule amounts of time (i.e., milliseconds), it’s more efficient for at-scale data encryption (i.e., for larger organizations with higher web traffic).

To encrypt your website’s connections, you need to have an SSL/TLS certificate installed on your server. It also requires the client and server to introduce themselves and exchange essential information to create a secure encrypted session. This back-and-forth process is called the TLS handshake, of which most browsers support two varieties — TLS 1.2 (most common) and TLS 1.3.

Here’s an overview of how the TLS 1.2 handshake process works:

  • When a client (browser) connects to a server (website), the two parties exchange certain protocols about the cryptographic processes they support. The client sends a large, random prime value (called a “client random”).
  • The server sends its SSL/TLS certificate and public key to the client (browser), along with a “server random” value (yeah, same concept as the client random value) that can be used in combination with the client random to create a symmetric session key.
  • The client checks the server’s certificate and uses the server’s public key to encrypt the symmetric key values it sends back to the server. (The specifics vary based on which key exchange algorithm is used.)
  • Both parties use their exchanged data to calculate a symmetric session key (i.e., shared session key).
  • The client checks the server’s message authentication code (MAC) to ensure the handshake hasn’t been tampered with.
  • Both parties use the shared session key to create a secure, symmetric encrypted connection.
An illustration that shows the roles of private and public keys in the TLS 1.2 handshake.
Image caption: An illustration that shows the interactions between the client and web server during a TLS 1.2 handshake. It also shows the exchange of the server’s public key, how it never shares the private key, and how the server and client use that cryptographic key pair to ultimately create a shared session key that they’ll use for the rest of the session.

When it comes to the TLS 1.3 handshake, the process differs somewhat, particularly regarding the key exchange process. The idea is to streamline everything into a single roundtrip.

But the basic concept stays the same: the public-private keypair is used to securely exchange a symmetric key that’s used for the actual data encryption.

2. How Code Signing Uses Private and Public Keys to Secure Executables and Code

Let’s consider the uses of public-private key pairs in software security. The process for securing code, software, executables, etc. involves the developer or publisher using a code signing certificate to add a digital signature to their software executable. This process uses cryptographic keys and functions (i.e., hashing and encryption) to authenticate the developer/publisher who created the asset and validate that the file or code hasn’t been modified since it was signed.

Remember toward the beginning of this article we said that it’s not always the case that public keys encrypt and private keys decrypt? This is what we were referring to.

But what does this process look like in terms of how and when each key is used?

  • The developer applies a hash function (i.e., hash algorithm) to their software/code. This creates as fixed-length hash digest (i.e., hash value).
  • They use their private key to encrypt the resulting hash digest. This key must be stored on a secure device, such as a secure token or hardware security module (HSM), based on industry code signing baseline requirements.
  • The developer then uses their code signing certificate to create a digital signature and apply a timestamp (Note: the timestamp is optional but recommended) to the software.
  • Their digitally signed software is distributed or released with the developer’s public key and certificate attached.
A step-by-step illustration of how the code signing process works using a private key.
Image caption: An illustration that breaks down the process of how code signing works and where half of the public-private key pair comes into play.

So, where does the public key come into play? During the software verification process that happens on the client end:

  • The end user downloads the software. Their browser or operating system (OS) checks the digital signature to ensure it is valid, is trusted, and hasn’t been altered.
  • Their system will apply the developer’s public key to the digest to decrypt it. It then compares that original hash digest to one that the system creates to see if it matches.
  • If the hash values match, then they’ve got a winner. If the values don’t, Windows operating systems and browsers will warn the user that your software shouldn’t be trusted.
A step-by-step illustration of how the code signing verification process works using the corresponding public key.
Image caption: An illustration that breaks down the role of the public key in the code signing verification process when a user downloads or tries to install digitally signed software or code.

3. How You Can Use a Public-Private Key Pair to Digitally Sign Documents

When we talk about document signing, we’re not talking about signing the electronic form of your handwritten signature. (That can be easily spoofed!) Instead, we’re referring to stamping your verifiable digital identity to a digital file (Word document, PDF, etc.) so people know it’s authentic and hasn’t been altered.

A side-by-side set of screenshots that shows the differences between how different types of electronic (left) and digital signatures (middle and right) display.
Image caption: An illustration that shows the difference between digital signatures (middle and right) and an electronic signature (left).

Fun aside: A digital signature is a type of electronic signature, but not all types of electronic signatures are digital signatures. A little confused? Check out my former colleague’s article if you want to learn more about the difference between electronic and digital signatures. Now, back to the main topic at hand…

As you’ve probably now guessed, to digitally sign a document, you must have a document signing certificate. So, what’s the role of the public and private key in this affair? Frankly, it’s similar to what the private key does in the code signing process we described moments ago:

  • The document creator applies a hash function to their Word or PDF file. This creates a hash digest or hash value.
  • They apply their private key to encrypt the file’s hash digest. Much like with the code signing process, your document signing key also must be stored on a secure device (token, HSM, etc.) or in a key vault.
  • The file owner then uses their document signing certificate to create the digital signature. They have the option of adding a timestamp to the file as well.
  • The digitally signed document is now ready for use.
public and private key pair graphic: An illustration that walks through the process of how document signing works and the role the securely stored private key plays in it.
Image caption: This graphic illustrates how a document signing private key is used to help create a digital signature for Microsoft Office documents and PDFs.
  • When the end user downloads the file, their device will check its digital signature.
  • Their system will apply the developer’s public key to the digest to decrypt it. They then compare that original hash digest to one that the system creates to see if it matches.

Now, it’s time to shift gears and move on to signing email communications.

4. How Public-Private Key Pairs Make Email Signing Possible

Email signing is a process that enables an email sender to prove that they sent the email and that the message didn’t come from an imposter. This process uses an email signing certificate (also called a client authentication certificate), which they install onto their device or import to their email client.

An example screenshot of the Certificate Manager where you can store certificates on a Windows device
Image caption: An example screenshot of email signing and client authentication certificates that are installed in my Windows Certificate Manager.

So, what does this email signing process look like, and where does a public-private key pair fit into the equation?

  • When digitally signing an email, the sender applies a hash function/algorithm to the message.
  • The sender applies their private key to encrypt that hash digest/value to create the digital signature.
  • The sender attaches their email signing certificate and public key to the outbound email. Together, this creates the digital signature block.
An illustration that demonstrates how the email signing process works and the role that the user's private key plays in it.
Image caption: A screenshot of how the code signing process works and where the cryptographic key comes into play in digitally signing the email.

Once the message is received:

  • The email recipient uses the sender’s public key to decrypt the email’s hash digest.
  • The recipient will compare this to a hash they generate to see if it matches.
  • If it matches, then the recipient can feel confident that the email is authentic.

To learn more about certificate-signed emails, check out our Hashed Out article that will walk you through how to import and use an S/MIME certificate in Outlook.

5. How Public-Private Key Pairs Enable Secure, Encrypted Email Communications

Email encryption is the process of randomly scrambling the contents of the email (words, images/graphics, attachments, etc.) to transform it into an unreadable form before the user hits the “send” button. However, what it doesn’t encrypt is the email header information.

Encrypting an email is akin to sealing secret, coded messages inside a secure cargo container; this way, it’s safe from being viewed in transit or while sitting at the arrival location (while sitting on the email server). This is why it’s sometimes called end-to-end encryption— because it’s protected from one endpoint to the other.

So, what’s this process look like in terms of how the public-private key pair is used? It’s time to shake things up a bit. (NOTE: Both the email recipient and sender must have an email signing certificate installed on their devices.)

  • The email recipient must send their public key to the email sender.
  • The email sender will then draft an email and add any attachments.
  • When the email sender encrypts an email, they’ll use the email recipient’s public key to do so.
  • Once the email is encrypted, they’ll send it to the recipient.
  • When the email recipient receives the email, their email client will use the recipient’s private key to decrypt the message. This will unscramble the message so that it can be read.
Public private key pair graphic: An illustration that breaks down the roles of public and private keys in the email encryption and decryption process.

Image caption: An illustration that demonstrates how email encryption works and how the public and private keys are used within that process.

Want to learn more about how to send encrypted emails? We’ve got you covered in this article that walks you through the process on three major email platforms.

Let’s Wrap This Up

Although you don’t need to know the intricacies of how public-private key pairs are used in public key cryptography, it certainly doesn’t hurt to learn. Cryptographic keys are essential to everything relating to security on the internet. Whether it’s securing the sensitive data submitted to your website or protecting the confidentiality and integrity of your emails, documents, and files, public key cryptography couldn’t exist without the security of your public-private key pair.

Public-private key pairs help to enable the following:

  • Authentication — This boils down to digital identity validation and verification. It’s what enables someone to know that another entity (i.e., a website, email sender, software publisher, document creator, etc.) is legitimate.
  • Data integrity — Public-private key pairs, in combination with cryptographic processes like hashing and encryption, make possible the digital signatures that prove the veracity of messages and files.
  • Non-repudiation — This entails validating that data came from the party in question and didn’t originate from an unverified source, so long as the private key is kept secure.

That last sentence brings us to our next point. Digital trust, the foundation of which is public key cryptography, is at the heart of internet security. If you can’t trust that the identity of the website, software developer, document creator, or email sender is legitimate, then how can you trust that any data you send or receive from them is safe and can be trusted? You can’t.  This is why it’s crucial to keep your private keys secure.

We hope this article underscores the importance of securely managing and storing your private keys. By keeping those critical assets secure, you’re preventing all of your (and your customers’) sensitive data from falling into the wrong hands.

Author

Casey Crane

Casey Crane is a regular contributor to and managing editor of Hashed Out. She has more than 15 years of experience in journalism and writing, including crime analysis and IT security. Casey also serves as the Content Manager at The SSL Store.