If you see the little padlock in front of the web address, a public key has already been doing its job, without you realizing that it has been. A public key is one of a pair of cryptographic keys: a long string of numbers that is accessible to everyone and can be used for public key cryptography and which is used in conjunction with a private key that is kept secret and hidden from everyone. They are the core of public key cryptography or asymmetric encryption, which is the system that prevents people from reading your online banking, email, messaging apps, and most of the modern internet.
This guide covers what a public key actually is, what one looks like in practice, the math that makes the whole system trustworthy, and the dozen or so places you’re already relying on one today without realizing it.
The actual public key is
A public key is just a very large number, or a few numbers generated by a mathematical algorithm. It is linked to a corresponding private key in a way that is reasonably easy to calculate from the public key, but cannot be calculated from the private key with any computer that exists today. That is the whole reason the system works: you can give a stranger or a bank or a whole country your public key and they cannot derive any practical means to work out your private key.
A good way to imagine it is a padlock you’ve had duplicated a thousand times and sent out to anyone who would want to send you something private. After all, anyone can click on one of those padlocks and shut a box, but only you with the one key will be able to open it up again. You didn’t give that key out. Padlocks you only gave out.
That’s the reverse of the way encryption was. Older, symmetric systems require a single shared key for locking and unlocking, which means that the sender and receiver must agree on the key in advance, typically by meeting in person or relying on a trusted courier not to look at the key. That was abandoned with public key cryptography, and when Whitfield Diffie and Martin Hellman published their 1976 paper announcing public key cryptography, they declared that cryptography was “on the brink of a revolution.
Public keys are actually created through an asymmetric algorithm, typically RSA, elliptic curve cryptography (ECC), or the Digital Signature Algorithm (DSA), and have an identical private key that is also a result of the same algorithm. One key will encrypt something and the other key will decrypt it. If one key is used, only the other could be used to verify it is correct. But the two-key symmetry, not a single shared secret, is what the word asymmetric means.
What a public key actually looks like
A public key is really just some text, a block of base64 characters with a couple lines of headers. An RSA public key in the common PEM format begins with a line that starts with “BEGIN PUBLIC KEY” and continues for several lines of characters that look like jumbled data, ending with a line that reads “END PUBLIC KEY”:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwT8mK2jXFhs93pR0lYqZ
Qm3o2Nc7fL9vZk1sHwXeR5tPdCq8YbNn4Uo6VJrM7Lp1Xz2sKfWa9dQeTgHiVoBc
p3Rm8Nz1sLdKq7EwYh2Vt9BpXn4Uc6FrJa8Gk1MsWzHb0PdVq3Rt7CfLn9YoKm2S
...
-----END PUBLIC KEY-----Inside that Base64 wrapping is a well-defined binary structure, which is, at the end of the day, a couple of plain numbers: a modulus and a public exponent for RSA.
If you have ever configured SSH access to a remote server, you will have encountered a public key in a shorter form: a single line beginning with ssh-rsa or ssh-ed25519 followed by a long unbroken string and which may contain a comment (usually a username or hostname). That one line is the entire public key, it’s quite short and can be pasted into a chat message but is mathematically bound to a private key that never leaves the machine that generates it.
When your browser displays that padlock, it’s reading your website’s certificate, which includes a public key and identity information: the domain name, certificate authority, and expiration date. The container format will vary by case, but it should always be understood that the public key should be copied and sent out by email and generally be made public after all, if an attacker sees it, they can’t learn anything about the secret key with which it is paired.
The actual workings of the key pair
This is based on the mathematics of what cryptographers call a trapdoor function, one that is easy to compute in one direction but, in the absence of certain secret information, is very costly to compute in the reverse direction. At the key sizes currently used, RSA’s version relies on the fact that multiplying two very large prime numbers is relatively quick for a computer, but factoring the resulting number back into the original two primes, if you don’t know them in advance, is much, much slower than the age of the universe using any classical factoring method currently known. The public key is created using that product. The two primes that generated your private key are stored there.
A different trapdoor is used in elliptic curve cryptography. While it is easy to expand a point on a curve by a large number, it is not feasible to go back to the result and obtain the number using current computers, called the elliptic curve discrete logarithm problem. Same principle but different maths: easy in one direction, virtually impossible in the other.
That is the one-sided aspect that makes a public key public. If someone encrypts a message using your public key, he is executing the easy part of that trapdoor function. To decrypt the message, reversing it will need the private key, which is the shortcut. Even after decades of intensive research by cryptographers and intelligence services, no classical shortcut has been published that functions just from the public side, at the key lengths recommended today.
Two jobs a public key does: encrypting and verifying signatures
In asymmetric encryption, there are two separate tasks performed by a public key, and it is one of the most frequent mistakes that causes confusion. The first one is called encryption. You send an encrypted private message to someone using their public key and it can only be decrypted by their private key. This is how information is protected when it is sent using HTTPS, encrypted e-mail, or secure messaging: the recipient locks the box with her public key and only she can open it with her private key.
The second one is working in the other direction: digital signatures. You sign a message with your private key, so that anybody with your public key can check that the message is really from you and that it hasn’t been tampered with in transit. In fact, no one signs an encrypted message, since that would be very slow! Instead, the software puts the message into a hash function, which generates a short, fixed-length print of the contents of the message, and this print is the content signed with the private key. The recipient hashes the message, decrypts the signature with his or her understanding of the sender’s public key and verifies whether the two fingerprints correspond. The fingerprints will not match if you change even one single character of the original message, and the signature will not even work.
It is important to remember this distinction since it reverses the role of which key does what. Encryption is always with the recipient’s public key for confidentiality. You sign with your own private key, for authenticity. That’s the second use, of course: a public key enables anyone to verify that a signature is valid without ever having the ability to make a copy of the private key that generated it, and a growing number of countries recognize a valid digital signature as equivalent to a handwritten one.
A short history: a classified discovery and a public revolution
Explanations of public key cryptography typically start in 1976 when Whitfield Diffie, Martin Hellman and Ralph Merkle published “New Directions in Cryptography”, a work that proposed a way for two parties to exchange a secret key over a public, untrustworthy channel without meeting each other in person. A year later, Ron Rivest, Adi Shamir, and Leonard Adleman followed with RSA, the first algorithm that fully uses the same asymmetric idea for both encryption and digital signatures, and the one that still bears their initials today.
The one thing that most articles about this topic don’t mention is that this very same idea had already been discovered and “quietly” buried years earlier within British intelligence. GCHQ mathematician James Ellis worked out in 1970 that what he termed non-secret encryption should be theoretically possible but could not see how to make it. In 1973 it was solved by a young GCHQ recruit named Clifford Cocks, whose method is mathematically equivalent to RSA, four years prior to the work of Rivest, Shamir and Adleman. Malcolm Williamson, a year later, worked out a key-exchange technique equivalent to that which was later published by Diffie and Hellman. It was never published at the time. The work was classified by GCHQ, and it remained secret until 1997, when the same mathematics was discovered in the academic and commercial world and an entire industry was established around it.
The point to mention every time this who really invented this? question that arises in cryptography is that the mathematics was there for anyone to discover, and in this instance it was discovered twice independently, on both sides of the classification wall.
The algorithms behind public keys: RSA, ECC, DSA, and Diffie-Hellman
Not all public keys are created equally. The vast majority of what is in use these days is covered by four families of algorithms.
The oldest of the group, RSA relies on the difficulty of factoring the product of two large prime numbers. While it is slower than other methods and requires a large key compared to the other methods, it is supported almost everywhere and thus it remains in heavy use for TLS certificates, email encryption, and code signing, with a key size of 2048 bits being the practical minimum that is used today.
With elliptic curve cryptography, the equivalent level of security can be achieved with much smaller keys. Due to the equivalent security to a 3072-bit RSA key, 256-bit ECC key generation is faster, certificates are smaller, and it consumes less battery – that’s why it’s now the default for mobile devices, IoT hardware and existing TLS deployments. The two variants that you will encounter most frequently are ECDSA (signature variant) and ECDH (key exchange variant).
DSA (Digital Signature Algorithm) was designed for signature and uses the DLP. It is still recommended for use by the U.S. federal government, but has been mostly superseded by ECDSA in more recent deployments.
Diffie-Hellman, meanwhile, doesn’t encrypt anything directly. It is a way for two parties to agree on a common key over an insecure communication line, to be used subsequently for quick symmetric cryptography. Almost all secure connections nowadays start with some sort of Diffie-Hellman or elliptic-curve variant of it, where the pair of parties negotiate a temporary public key before a single byte of data is transmitted.
Where you’re already using public keys every day
Public key cryptography is not a tool that’s just for the cryptographers. It works unobtrusively when you are doing most of your activities online.
It is crucial for all websites that support secure communications via the HTTPS protocol. When the padlock appears in your address bar, the site that is displaying its public key in a certificate is using the public key to negotiate an encrypted connection before displaying any images.
When using encrypted email, whether as PGP or GPG (via the GPGME tools) or in the S/MIME standard incorporated into most corporate email systems, the recipient’s public key is used to encrypt the message, and the sender’s secret key to sign it, so that the recipient can be assured that, in addition to being confidential, it actually came from the sender it claims.
Developers and system administrators are able to log in to remote servers via SSH keys instead of passwords. The public key is stored on the server’s list of authorized keys, while the private key is located on a laptop, and no data is sent that could be stolen or guessed.
Cryptocurrencies such as Bitcoin and Ethereum use a public key, or a hash of one, as a wallet address that anyone can send funds to the same address you’d look up on a blockchain explorer to check its balance or transaction history while the private key is the only thing able to authorize a transaction out of that wallet. It’s also why losing a private key means losing the funds permanently, with no password reset available, and it’s exactly the risk a hardware wallet is built to reduce by keeping that private key offline and away from anything connected to the internet.
When software is updated, mobile applications installed or even Linux package repositories, these are digitally signed with a developer’s private key, meaning that the device can use a public key to check the software wasn’t modified along the way into something malicious. The newer passkey logins provided by Google, Apple and an increasing number of websites are, under the hood, a public-private key pair created on your phone or laptop, with the public part stored on the website and the private part in your device.
Public key vs. private key vs. symmetric key
These three terms are used interchangeably and it is helpful to make a distinction between them.
Public key is the part of an asymmetric key pair that’s intended to be published. It is a value that is used to encrypt data or to verify a signature, and if an attacker has it, then he has no useful shortcut to the private key. The other half of that same pair is a private key. It should never be shared, it decrypts what the public key encrypted and it generates the signatures that the public key checks. If lost, there is no reset button, unlike a password, it is lost or permanently compromised, depending on the manner of its loss.
A symmetric key is a very different beast: a single key for both encrypting and decrypting, it is kept secret between the two parties before communication commences. It’s super fast, compared to asymmetric encryption, and is responsible for the majority of the data involved in an established connection, using AES as the algorithm for practically all of it. The issue is that the two users must somehow agree on that common key and the point of public key is to avoid that problem.
In practice, almost no real system picks one approach over the other. The hybrid approach is used in TLS, encrypted email, and message applications: asymmetric keys are used to exchange the first few messages for the initial handshake and identity verification, but symmetric keys are used for the bulk data in the video or file transfers because it is too slow to use the asymmetric keys.
Common misconceptions about public key cryptography
Some assumptions about public key systems are so widespread (even in the tech community!) that it is worthwhile to dispel them here.
The first is that because public key encryption has two keys vs symmetric encryption’s one, it is inherently more secure. It isn’t. The security of both systems is dependent on key length and the number of operations required to solve the underlying mathematical problem, not the number of keys. Even though a well-implemented symmetric cipher such as AES-256 does not require an RSA key, it is not weaker than RSA.
However, the second is that public key cryptography has proved to be an obsolete technology for symmetric encryption. It has not, and in fact, as the above hybrid systems illustrate, it cannot, asymmetric operations are simply too expensive for bulk data, and it is symmetric encryption that is doing the hard work, almost everywhere public key cryptography appears.
The third is that, with a public key, key distribution is solved without the necessity of any of the coordination symmetric systems. It doesn’t solve that issue, it just moves it. Now you must have a secure method to determine that a public key really is that of the purported owner, and that’s why public key infrastructure was invented, with its own attendant overheads of certificate authorities, revocation checks, and trust decisions.
How strong does a public key need to be?
The larger the key, the more resistant to a brute-force attack the public key will be, however, larger is not necessarily better, as there is a compromise between performance and size, and the different algorithm types require vastly different key sizes to provide equal levels of security.
The lowest value currently in use for RSA is 2048 bits. NIST guidance allows use until 2030, when it is recommended to be retired, and use 3072-bit RSA or equivalent elliptic curve key. At least 2048 bits are already mandatory for major browsers and certificate authorities and 1024-bit RSA keys, formerly the standard, have been unsafe and have not been issued for public certificates for over 10 years. With long-lived keys, like those of a certificate authority (CA) itself, 4096-bit RSA is common, because it provides a greater margin for error, but it takes more processing time.
ECC can achieve the same strength using much shorter keys. A 256-bit ECDSA key with the P-256 curve is about as secure as a 3072-bit RSA key, while a 384-bit ECC curve puts this further still, so ECC has been the de facto standard for everything with limited resources: smartphones, industrial sensors, etc.
However, it is not a rule that the longer the object is, the safer it is. A key pair created with a weak and/or predictable random number generator (RNG) can be cracked, and a private key left thoughtlessly in a code repository, an unencrypted backup file, or a shared server defeats even the best math. In practice, most weaknesses of public key systems are due to errors in key management, rather than someone overcoming the cryptographic system itself.
What happens to public keys when quantum computers arrive
The one scenario that could actually undermine today’s public key algorithms is not a faster classical computer, but a quantum computer powerful enough. If a quantum computer is sufficiently large and stable to actually execute it, then Shor’s algorithm can factor large numbers, and this can be used to break both RSA and Diffie-Hellman and ECC. It has not been constructed yet, and while it’s inaccessible today, there are credible estimates from experts that a cryptographically interesting quantum computer may exist sometime in the 2030s, though this estimate appears to be shrinking as the research advances.
This is actually more urgent than it sounds, due to a threat model known as harvest now, decrypt later: an adversary could capture encrypted traffic today, and just wait for a quantum computer to come along later that could decrypt it, and it becomes a severe problem for any traffic that must remain confidential for years or decades and is perfectly safe against any computer available today.
That’s why the shift to post-quantum cryptography is already underway rather than hypothetical. NIST in August 2024 published the first three standards for post-quantum technologies: ML-KEM for key exchange, ML-DSA and SLH-DSA for digital signatures, none of which are based on RSA or ECC, and were selected with mathematical properties specifically designed to withstand quantum attacks. The standardization process is ongoing, one more candidate signature algorithm that was being assessed, called HAWK, was withdrawn after a vulnerability was found in it, as confirmed by NIST in 2026. Migration deadlines have already been set for the next decade by government agencies, while browsers, operating systems and key cloud providers have started to implement hybrid connections, which combine a classical key exchange with a post-quantum one to ensure that traffic remains secure if one of the two methods fails.
None of this means that the public key which is stored in your browser’s certificate today is compromised, it is not, at least not for anything that exists today. It does imply that a public key is larger than any individual algorithm, however. RSA and ECC are just the form we’re using while the next generation is being created.
The bottom line
The public key is something you don’t need to remember, secure, or be concerned about someone stealing, that is its whole purpose. That’s how the system can enable trillions of encrypted connections between billions of devices that never physically meet, not even in the real world. Almost all the responsibility is on the private key – back it up sensibly, never send it anywhere, and guard it carefully because everything a public key promises of confidentiality, a verified signature, a trusted identity is dependent on the one file staying exactly where it belongs. The principle is sound, whether you’re reading this because a server just asked you to provide an SSH key, because you were curious about what that padlock icon does, or because you were looking ahead to a post-quantum future: two mathematically related keys, one you can give to the entire world, and one you never will, are doing more to keep the internet honest than almost any other piece of technology you use every day.
