Public Key vs Private Key: How Do They Work?

Public Key vs Private Key: How Do They Work?

1 Star2 Stars3 Stars4 Stars5 Stars (13 votes, average: 4.69 out of 5)

Explore the roles of the public key and private key in public key cryptography and learn how they make secure third-party communications possible

Public key vs private key — these are two very important terms to understand and differentiate in public key cryptography, or what’s known as asymmetric encryption. You see, public key cryptography is what makes it possible to communicate securely with people you do or don’t know across the internet by enabling you to identify them and encrypt your communications. Having both a public key and private key is necessary for this process.

But what are a public key and private key? Why do they matter, and what are the differences between them? In this article, we’ll talk about public key vs private key and their roles in data privacy and identity verification.

Public Key vs Private Key: The Differences Between Them

Encryption means converting plaintext data in a gibberish format in a way that no unauthorized person can read, interpret, or alter it without a special key. A cryptographic key is a long string of random, unpredictable characters. If you use one key to encrypt and decrypt data, then it means you’re using symmetric encryption.

Don't make the same mistakes

Yahoo, Equifax, Home Depot,

LinkedIn, and Ericsson did!

Get our free 15-point checklist and

avoid the same costly pitfalls.

Please Select Your Country
  • Afghanistan
  • Albania
  • Algeria
  • Andorra
  • Angola
  • Antigua & Deps
  • Argentina
  • Armenia
  • Aruba
  • Australia
  • Austria
  • Azerbaijan
  • Bahamas
  • Bahrain
  • Bangladesh
  • Barbados
  • Belarus
  • Belgium
  • Belize
  • Benin
  • Bermuda
  • Bhutan
  • Bolivia
  • Bosnia Herzegovina
  • Botswana
  • Brazil
  • Brunei
  • Bulgaria
  • Burkina
  • Burundi
  • Cambodia
  • Cameroon
  • Canada
  • Cape Verde
  • Central African Rep
  • Chad
  • Chile
  • China
  • Colombia
  • Comoros
  • Congo
  • Congo {Democratic Rep}
  • Costa Rica
  • Croatia
  • Cuba
  • Curaçao
  • Cyprus
  • Czech Republic
  • Denmark
  • Djibouti
  • Dominica
  • Dominican Republic
  • East Timor
  • Ecuador
  • Egypt
  • El Salvador
  • Equatorial Guinea
  • Eritrea
  • Estonia
  • Eswatini
  • Ethiopia
  • Fiji
  • Finland
  • France
  • Gabon
  • Gambia
  • Georgia
  • Germany
  • Ghana
  • Greece
  • Grenada
  • Guatemala
  • Guinea
  • Guinea-Bissau
  • Guyana
  • Haiti
  • Honduras
  • Hungary
  • Iceland
  • India
  • Indonesia
  • Iran
  • Iraq
  • Ireland {Republic}
  • Israel
  • Italy
  • Ivory Coast
  • Jamaica
  • Japan
  • Jordan
  • Kazakhstan
  • Kenya
  • Kiribati
  • Korea North
  • Korea South
  • Kosovo
  • Kuwait
  • Kyrgyzstan
  • Laos
  • Latvia
  • Lebanon
  • Lesotho
  • Liberia
  • Libya
  • Liechtenstein
  • Lithuania
  • Luxembourg
  • Macedonia
  • Madagascar
  • Malawi
  • Malaysia
  • Maldives
  • Mali
  • Malta
  • Marshall Islands
  • Mauritania
  • Mauritius
  • Mexico
  • Micronesia
  • Moldova
  • Monaco
  • Mongolia
  • Montenegro
  • Morocco
  • Mozambique
  • Myanmar
  • Namibia
  • Nauru
  • Nepal
  • Netherlands
  • New Zealand
  • Nicaragua
  • Niger
  • Nigeria
  • Norway
  • Oman
  • Pakistan
  • Palau
  • Panama
  • Papua New Guinea
  • Paraguay
  • Peru
  • Philippines
  • Poland
  • Portugal
  • Qatar
  • Romania
  • Russian Federation
  • Rwanda
  • St Kitts & Nevis
  • St Lucia
  • Saint Vincent & the Grenadines
  • Samoa
  • San Marino
  • Sao Tome & Principe
  • Saudi Arabia
  • Senegal
  • Serbia
  • Seychelles
  • Sierra Leone
  • Singapore
  • Slovakia
  • Slovenia
  • Solomon Islands
  • Somalia
  • South Africa
  • South Sudan
  • Spain
  • Sri Lanka
  • Sudan
  • Suriname
  • Sweden
  • Switzerland
  • Syria
  • Taiwan
  • Tajikistan
  • Tanzania
  • Thailand
  • Togo
  • Tonga
  • Trinidad & Tobago
  • Tunisia
  • Turkey
  • Turkmenistan
  • Tuvalu
  • Uganda
  • Ukraine
  • United Arab Emirates
  • United Kingdom
  • United States
  • Uruguay
  • Uzbekistan
  • Vanuatu
  • Vatican City
  • Venezuela
  • Vietnam
  • Yemen
  • Zambia
  • Zimbabwe

Contact details collected on InfoSec Insights may be used to send you requested information, blog update notices, and for marketing purposes. Learn more...

Public key vs private key: A graphic that illustrates how symmetric encryption works using the same (identical) key

But if you’re using two separate keys — one to encrypt data and the other to decrypt it — then you’re using asymmetric encryption (public key encryption). The keys are known as the public key (encryption key) and the private key (decryption key).

Public key vs private key: A graphic that illustrates how asymmetric encryption works using two separate keys

As we pointed out earlier, there are two separate keys involved in public key cryptography. Imagine a vault that has two separate keys. One can lock the vault, but the same key can’t open it. This means you’d need a different key to unlock the vault. In public key cryptography, it’s much the same way: there are two keys — one that can encrypt the data and the other that can decrypt it. These keys are separate yet mathematically related to each other. That’s because they’re generated using an asymmetric algorithm that binds the public key to the private one.

To learn more about the differences between them, be sure to check out this article on the differences between asymmetric vs symmetric encryption.

What Is a Public Key & How Does It Work?

Within public key infrastructure, the public key encrypts the data. It’s known as the public key because it can be openly distributed, and anyone can use it for encryption. As soon as the data is encrypted using a public key, you can neither interpret nor guess the original content of the data from the ciphertext nor use the same key (i.e., public key) to unlock it.

Your public key is generated using complex asymmetric encryption algorithms. The length of the public key depends upon the algorithm it is made with. In general, the key size varies from 128 bits to 4096 bits. The Certificate Authority/Browser Forum (CA/B Forum) provides guidance for the ideal minimum public key size. For example, based on the CA/B Forum’s current guidelines, all CAs shall confirm that:

  • The RSA public key is at least 2048 bits, or
  • That one of the following ECDSA curves is used: NIST P-256, NIST P-384, or NIST P-521.

An RSA public key looks like this:

Public key vs private key graphic: A screenshot of a public key, which is a long string of random and unpredictable characters and numbers
Private key vs public key graphic: This screenshot of’s RSA 2048-bit public key is an example of what a public key looks like.

The mathematical algorithms used to create the public key (and private key) are:

So, what is a difference between an RSA public key versus one that’s ECC? The key sizes, for one. RSA keys are significantly larger than ECC keys, yet ECC keys are just as strong. Second, the keys are calculated in different ways. An RSA public key is the result of two massive prime numbers and a smaller number, whereas an ECC public key is an equation that calculates a specific point on an elliptic curve.

What Is a Private Key & How Does It Work?

This key can decrypt ciphered data (i.e., encrypted data). Each public key has a corresponding private key. All the pairs of public and private keys are unique. The private key must be kept secret with the owner (i.e., stored safely on the authorized device or non-public-facing server). For SSL/TLS certificates, you generate your private key as part of the key pair that gets created with your certificate signing request (CSR). This means that even the certificate’s issuing CA doesn’t get to see or have access to your public key.

Because your key is secret, it means that you need to keep it safe and know where it is at all times. If your private key becomes lost, then you’ve got your work cut out for you and will need to re-issue your certificate.

As you can imagine, it’s almost impossible to guess a private key from its corresponding public key because it’s generated with strong entropy (randomness). As such, it would take even a modern supercomputer thousands of years to crack a private key via a brute force attack. Thus, no one can decrypt the data except the authorized device where the private key is stored.

A private key looks like this:

Public key vs private key graphic: This image, which has been edited to remove sensitive information, showcases an example RSA private key
An RSA private key example in public key cryptography.

A Quick Overview Down the Differences: Public Key vs Private Key

Looking for a quick visual to help you see the differences between a public key and private key? Then look no further:

Public KeyPrivate Key
Can be openly distributed Must be kept a secret
Used for encryptionCan be used for decryption in asymmetric encryption, or encryption AND decryption in symmetric encryption
Authenticates digital signature signed with the corresponding private key (when used in certificate pinning)Insert the digital signature (encrypting the hash)
Stored inside the digital certificates, outgoing emails, and executablesStored in authorized devices and non-public-facing servers

Public Key vs Private Key: Their Roles in Data Privacy & Security

When you want to protect data while it’s in transit or at rest, public key cryptography comes in handy. One endpoint encrypts the data using the recipient’s public key and sends it. The recipient decrypts it by using the corresponding private key. If anyone else in the middle intercepts the data, they can’t unlock, read, or otherwise interpret it without the private key.

Hence, asymmetric encryption protects the plaintext data from being exposed due to:

  • Man-in-the-middle attacks,
  • Data leaks, and
  • Data theft.  

Just to quickly clarify — asymmetric encryption doesn’t stop these types of attacks and data leaks or theft from taking place. But what it does do is stop anyone from being able to read and access the unencrypted/plaintext data. Without the corresponding private key to decrypt the data, all the bad guys will see is gibberish.  

A classic example of how to think of a public key and private key is to consider your email address and password.Your email address, in this case, represents a public key, which is available to the general public, and anyone who has access to it can send you an email. But only the password holder (i.e., you) can open and read the email the account contains. Here, the password serves as a type of private key.

All public key and private key pairs are unique. If you’re signing for a new user ID on a website or application, the system notifies you if your selected user ID is already in use. You must have a unique pair of a user ID (which can be an email, phone number, ID card number, etc.) and password.

SSL/TLS Certificate

In the same way, the SSL/TLS certificate protects the data transfer between a browser and the website’s server using public key cryptography. The website owner installs an SSL certificate on their website and relies on the unique set of public and private keys for that certificate. There are millions of sites using SSL/TLS certificates. But none of them have the same key pairs.

When a website visitor tries to open a website, their web browser engages in a process with the website’s server that’s known as a TLS handshake. As part of this process, the browser (client) generates a random pre-master secret, encrypts it using the server’s public key, and sends it to the server. The server decrypts the pre-master secret using the corresponding private key and uses it to compute a symmetric session key.

All the data transferred between a user and a website for the rest of the session is encrypted using the session key — meaning that it’s transmitted via symmetric encryption. No intruder can access the session key without a private key. It’s this initial use of public key cryptography that makes it possible to exchange session keys to engage in symmetric encryption for the rest of the session. This process protects data transmissions between a website and its visitors.

Public key cryptography is also used in the following digital certificates to protect the data:

Public Key vs Private Key in Identity Verification

Another usage of a public key and the private key is identity verification and digital signatures.

In digital signatures, the sender inserts a digital signature using a private key. The recipient verifies the authenticity of the signature with the senders’ public key. No one can modify, copy, or delete the digital signature except the private key holder (i.e., the authorized sender). Digital signatures, with other measures, give assurance about the sender’s identity and the integrity of the data.

Email Signing Certificates

When you install an S/MIME certificate on your email client, it generates a unique pair of public and private keys. It stores the private key on your server and sends the public key with all outgoing emails. You can digitally sign your emails using a private key stored on your device. The recipients receive the email along with the public key, which they use to verify the signature. It gives the recipients assurance about the email sender’s identity.

A digitally signed email looks like this:

A combination of screenshots that showcase what an email signing certificate and digital signature look like

Code Signing Certificates

These certificates are used by software publishers to sign executable software, scripts, drivers, and applications. After completing a piece of software, the developer digitally signs it using their private key. Whenever the users try to download the software, their devices receive the software’s public key to verify the signature.

At the time of downloading, a security window pops up. If the digital signature is valid, the dialogue box shows the publisher’s name in it. If there is no digital certificate, the publisher’s name will be shown as “unknown.” A code signing certificate gives assurance to the users that the software is coming from a verified publisher.

A screenshot showing two Windows messages, the first of which warns about an unknown software publisher and the second shows a verified publisher
A side-by-side comparison of what it looks like to end users who download your software when you do or don’t use a code signing certificate.

As you can see in the screenshot above, the security dialogue box is showing “Microsoft Corporation” in the verified publisher’s field. It is Microsoft’s digital signature that no one can modify, change, replicate, or remove. A third-party certificate authority conducts a rigorous verification process before granting a code signing certificate to a publisher.

Public Key vs Private Key in Two-Way Authentication

The public key and private key are also useful for two-way authentication, or what’s known as client authentication. Organizations don’t want any outsiders to access their intranet websites, development and testing sites, and some resources made strictly for internal usage. In the same way, some sensitive internal emails shouldn’t be opened by outsiders. In this situation, the private key and public key helps to develop two-way authentication.

Some certificates (like “two-way SSL/TLS certs,” or what are known as personal authentication certificates or client authentication certificates) can be installed on employees’ office devices to enable two-way authentication where the server can verify the client. (With traditional SSL/TLS certificates, for example, it’s typically one-way authentication in that the client authenticates the server, not vice versa.)

Example: Suppose Alice and Bob are working for an organization with installed email signing certificates on their email clients. When Alice sends an email to Bob, she uses Bob’s public key and her private key to encrypt and sign the email. When Bob receives the email, he decrypts it using his private key and Alice’s public key. No one else can open and read the email content because they don’t have the private key.

Personal Authentication Certificate: In the same way, personal authentication certificates (client certificates) are installed on the employees’ company devices (desktop, laptop, and even smartphones). Both the client and server have a set of a public key and private key. When employees try to open the website, the traditional TLS handshake process takes place first, where the server presents its SSL/TLS certificate, and the client authenticates it. After that, the client also provides its certificate for the server to authenticate.

Let’s understand this process a bit better with another example:

John is a remote software developer working for XYZ corporation. The company has developed an intranet website, which only employees can access. XYZ has provided a laptop to John for office work in which a client certificate is installed. Whenever John tries to open, his browser checks the website’s SSL/TLS certificate as part of the TLS handshake process.

As part of the handshake, John’s device needs to present its certificate, which the website’s server authenticates. Only once this process is complete can John access the intranet site. In this way, John can’t access from any device other than his office laptop.

Wrapping Up on Public Key vs Private Key

Encryption has two types. Symmetric and asymmetric. In symmetric encryption, there is only one key needed for encryption and decryption. That key must be kept secret by all endpoints and users. Key distribution and key management are challenges, and chances of compromise of key increase when a large number of endpoints are involved.

Asymmetric encryption (public key cryptography), on the other hand, is more secure when using large keys with strong entropy. That’s because two keys are involved (i.e., the public key and private key). The major difference between them is that the public key encrypts data whereas the private key decrypts it. Also, you can distribute public keys freely to many endpoints without worrying about security compromise. But the private key is a precious treasure that must be protected at any cost.

We hope this article has helped you to understand public key vs private key and their usage in public key cryptography.

About the author

Medha is a regular contributor to InfoSec Insights. She's a tech enthusiast and writes about technology, website security, cryptography, cyber security, and data protection.