Every time you load a website, send an encrypted email, or sign a blockchain transaction, public key encryption is doing the heavy lifting behind the scenes. AXL Research Hub covers this foundational topic because it touches nearly every corner of crypto and web security. If you’ve ever wondered how two strangers on the internet can exchange sensitive data without first agreeing on a shared password, the answer starts here, with a pair of mathematically linked keys.
What is public key encryption?
Public key encryption is a cryptographic system that uses two mathematically linked keys, one public and one private, to encrypt and decrypt data. It’s also called asymmetric cryptography or public key cryptography, and it stands apart from symmetric encryption, which relies on a single shared key for both locking and unlocking information.
The security behind this system rests on one-way mathematical functions. These functions are easy to compute in one direction but computationally infeasible to reverse without the private key. Factoring the product of two very large prime numbers is a classic example: multiplying them together takes a fraction of a second, but working backward from the product to find the original primes would take conventional computers an impractical amount of time.
A simple way to picture it: your public key works like a mail slot in a locked mailbox. Anyone walking by can drop a letter through the slot, but only you hold the key that opens the box. Messages go in easily; only the owner gets them back out.
Why public key encryption matters
Symmetric encryption traps you in a chicken-and-egg problem: before two parties can communicate securely, they need to share a secret key, but getting that key to the other side already requires the secure channel you’re trying to build. Public key encryption breaks the loop by letting you publish your public key openly so anyone can encrypt data to you, while only your private key can read it, no pre-arranged secret or risky handoff involved.
That single breakthrough enables confidentiality, authentication, digital signatures, and non-repudiation across the internet. HTTPS, the protocol that secures web browsing, depends on it. According to the Google Transparency Report, desktop users load more than half of viewed pages over HTTPS. Behind that stat sit millions of TLS certificates issued every day. Let’s Encrypt reported a peak issuance rate of 340,000 certificates per hour in January 2025, giving a sense of the scale at which public key infrastructure operates.
Beyond the browser, asymmetric cryptography is the foundation for secure email, file transfers, remote server login via SSH, blockchain transactions, and cloud services. It establishes trust through public key infrastructure (PKI) and digital certificates issued by certificate authorities, creating a chain of verified identities that stretches across organizations and national borders.
How public key encryption works
The full process moves through four stages: key generation, key exchange, encryption and decryption, and hybrid session establishment. Each stage builds on the previous one, and understanding them in order makes the whole system click.
Key generation
Everything starts with producing a public-private key pair. Algorithms generate these pairs based on hard mathematical problems. RSA key generation, for instance, relies on the difficulty of factoring large composite numbers. Elliptic curve key generation relies on a different hard problem, the elliptic curve discrete logarithm problem.
How random the input is directly affects how strong the resulting keys are. Weak or predictable randomness can produce key pairs that an attacker could reproduce, undermining the entire system before a single message is sent.
Once generated, the private key must stay secret at all times. There’s no recovery mechanism built into the math. If the private key is lost or stolen, you can’t regenerate it, and every message encrypted to the corresponding public key becomes permanently unreadable. For organizations, that risk means lost data, revoked certificates, and a scramble to reissue credentials. It’s a vulnerability that can’t be patched after the fact, only prevented through careful storage and access controls.
Larger organizations often generate separate key pairs for different purposes: one pair for signing documents, another for encryption, and ephemeral keys for short-lived sessions. Splitting responsibilities limits the damage if any single key is compromised.
Key exchange via public key infrastructure
A public key is only useful if the other party can trust it actually belongs to you. Without that trust, an attacker could swap in their own public key, intercept messages meant for you, decrypt them, and re-encrypt them with your real key before forwarding them along. This is the classic man-in-the-middle attack.
Public key infrastructure (PKI) prevents this by binding a public key to a verified identity through a digital certificate. A certificate authority (CA) acts as a trusted third party. It validates that you control the domain or identity in question, then issues a certificate containing your public key and the CA’s digital signature. Anyone who trusts that CA can verify your certificate and know the public key inside it is legitimate.
Public keys can also be distributed through directories or APIs, but in practice, CA-signed certificates are the standard for web traffic, email encryption, and most enterprise systems. The careful validation step is what makes the whole trust chain hold together.
Encryption and decryption
With a trusted public key in hand, the sender encrypts their plaintext message, producing ciphertext. Only the recipient’s corresponding private key can reverse that ciphertext back into readable plaintext.
This one-directional flow eliminates the need to exchange a secret key beforehand. If an eavesdropper intercepts the ciphertext in transit, they’re left with data that’s unreadable without the private key. Even possessing the public key that performed the encryption doesn’t help them, because the math only works in one direction.
Hybrid encryption with symmetric keys
Asymmetric encryption is computationally expensive. Encrypting a large file or a streaming video connection purely with RSA or ECC would be painfully slow. In practice, public key encryption is used to establish a shared symmetric session key, and then a faster symmetric algorithm handles the bulk data transfer.
The TLS handshake follows exactly this hybrid model. Asymmetric cryptography authenticates both parties and securely exchanges a session key. Once that key is in place, symmetric encryption, typically AES, protects the rest of the session. AES-256 uses a single 256-bit key and runs 14 rounds of substitution and mixing operations, which is orders of magnitude faster than performing the same work asymmetrically. AES was selected by NIST as the federal encryption standard and is required under FIPS 140-3.
A new session key is negotiated for each communication session. If an attacker compromises one session key, they can’t use it to decrypt past or future sessions. This property, called forward secrecy, keeps the damage contained.
Public key vs. private key
The two keys in an asymmetric pair serve complementary but distinct roles. Either key can technically perform the encryption step, with the other handling decryption, which is what enables both confidentiality and authentication workflows.
| Feature | Public key | Private key |
|---|---|---|
| Visibility | Shared openly | Kept confidential by its owner |
| Encryption role | Encrypts data sent to the key owner | Decrypts data encrypted with the public key |
| Signature role | Verifies digital signatures | Creates digital signatures |
| If compromised | Attacker can encrypt messages to the owner (not a security break on its own) | Attacker can decrypt messages, forge signatures, and impersonate the key owner |
| If lost | Can be redistributed | Encrypted data becomes permanently unrecoverable |
The asymmetry is the core principle: what one key locks, only the other can unlock. Compromise of the private key is the catastrophic scenario, because it breaks both confidentiality and identity verification at once.
Advantages over symmetric encryption
Public key encryption addresses several limitations that symmetric encryption can’t solve on its own.
- No pre-shared secret required. Two parties who have never communicated before can exchange encrypted data immediately. The sender only needs the recipient’s public key, which can be published openly without compromising security.
- Scales across open, untrusted networks. Symmetric encryption needs a secure channel to deliver the shared key, which is a problem when you’re communicating with thousands of different servers or users. Asymmetric encryption removes that obstacle entirely.
- Digital signatures and non-repudiation. Because the private key is held by a single party, a valid digital signature proves who created it. Symmetric systems can’t do this natively since both parties share the same key, so either one could have produced the message.
- Integrates with PKI. Public key encryption plugs directly into the certificate authority trust hierarchy, enabling verified identities across organizations and domains without requiring each pair of parties to arrange key exchange independently.
Disadvantages of public key encryption
You should know about several practical downsides before relying on asymmetric encryption in production.
- Slower than symmetric encryption. The math behind asymmetric algorithms is computationally heavier, which makes encrypting large data volumes directly with RSA or ECC impractical. That’s why the hybrid approach with symmetric session keys exists.
- Vulnerable to brute-force attacks with insufficient key lengths. Short keys can be cracked as computational power grows. Advances in hardware, or eventually quantum computing, could shrink the safety margin of keys that seem strong today.
- Private key loss is permanent. There’s no “forgot your password” flow. If the private key is gone, every piece of data encrypted to its corresponding public key is locked away forever, and any identity proofs tied to it are invalidated.
- Man-in-the-middle risk without certificate verification. If public keys are exchanged without CA-backed certificates, an attacker can substitute their own key and intercept communications transparently.
- Chain-of-trust vulnerability at the root CA level. If a root certificate authority’s private key is compromised, every subordinate certificate it has issued is potentially untrustworthy. This single point of failure sits at the top of the trust hierarchy and is why root CA key protection involves extreme physical and procedural safeguards.
Common public key encryption algorithms
Several algorithm families power asymmetric cryptography, each making different trade-offs between performance, key size, and security.
RSA
RSA is named after its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman. It relies on the computational difficulty of factoring very large numbers and remains the most widely deployed asymmetric algorithm, particularly in TLS/SSL certificates.
NIST recommends a minimum RSA key length of 2048 bits. For higher-assurance applications, 4096-bit keys are common. Longer keys provide a larger margin of safety, but they also increase the computational cost of every encryption and decryption operation, which is one reason ECC has gained traction as an alternative.
RSA’s history stretches back to 1977, but the conceptual groundwork was laid a few years earlier. In the mid-1970s, Whitfield Diffie, Martin Hellman, and Ralph Merkle published the ideas behind asymmetric key exchange, fundamentally changing how cryptographers thought about secure communication. It later emerged that researchers at Britain’s GCHQ had arrived at similar concepts in classified work before the public publications, though their findings weren’t declassified until years afterward.
Elliptic curve cryptography (ECC)
ECC is a family of algorithms that delivers security equivalent to RSA but with much smaller key sizes. A 256-bit ECC key provides roughly the same protection as a 3072-bit RSA key, which translates directly into less computational load, faster handshakes, and smaller certificates.
That efficiency makes ECC particularly well-suited for IoT devices and mobile environments where processing power and battery life are limited. ECDSA, one of the most common ECC-based signature algorithms, is widely adopted in SSH, JSON Web Tokens, DNSSEC, and zero-trust architectures. EdDSA is another variant, favored for high-performance digital signing. NIST recommends a 256-bit key length for ECC.
Diffie-Hellman key exchange
Diffie-Hellman isn’t an encryption algorithm in the traditional sense. It lets two parties agree on a shared secret over an untrusted channel by having each side contribute values that combine into the secret, so the secret itself never crosses the wire.
Variants of Diffie-Hellman underpin the key-exchange steps in TLS, IPsec, and SSH handshake protocols. It’s often paired with other algorithms that handle the actual encryption and signing once the shared secret is established.
Digital Signature Algorithm (DSA)
DSA was developed by NIST specifically for digital-signature use and meets Federal Information Processing Standards (FIPS) compliance requirements. Unlike RSA and ECC, DSA handles only signing, not encryption.
DSA has been largely deprecated for new deployments. Its reliance on shorter key sizes and older hash functions puts it behind both RSA and ECC in terms of security margins for modern applications.
Algorithm comparison: RSA vs. ECC vs. DSA
The choice of algorithm affects handshake speed, certificate size, device compatibility, and what operations you can perform. Here’s how the three compare side by side.
| Feature | RSA | ECC | DSA |
|---|---|---|---|
| Primary use | Encryption and signing | Encryption and signing | Signing only |
| Key size for strong security | 2048 bits minimum (NIST) | 256 bits (NIST) | 2048+ bits |
| Relative speed | Slower with large keys | Faster due to smaller keys | Moderate |
| Compatibility | Broadest; supported nearly everywhere | Widely supported; growing adoption | Legacy support; declining |
| Key size vs. security | Larger keys needed for equivalent security | Much smaller keys for comparable security | Similar to RSA |
| Current status | Standard for most TLS/SSL certificates | Preferred for mobile, IoT, and newer deployments | Considered outdated for new implementations |
The key-size difference between RSA and ECC for equivalent security is substantial. That gap drives most of the performance and efficiency advantages ECC holds, especially on constrained devices.
Digital signatures and authentication
Digital signatures prove two things at once: that a message came from the claimed sender, and that it hasn’t been altered in transit.
The process works like this: the sender runs the message through a hash function, producing a fixed-length digest. The sender then encrypts that hash with their private key, creating the digital signature. When the recipient receives the message and signature, they decrypt the signature using the sender’s public key to recover the original hash. They also hash the received message independently. If the two hashes match, the message is authentic and unchanged.
This mechanism provides non-repudiation, meaning the sender can’t later deny authorship. Only their private key or public key could have produced a signature that the corresponding counterpart successfully verifies.
Algorithms used for digital signatures include RSA, ECDSA, EdDSA, and DSA. You’ll find digital signatures in software distribution (code signing ensures an update actually comes from the developer), secure OS updates, legal document workflows, and certificate issuance itself, since a CA’s signature on a certificate is exactly this process.
How TLS/SSL uses public key encryption
The TLS handshake is the most common real-world application of asymmetric cryptography. Here’s how a typical connection is established.
- The server presents its digital certificate. This certificate contains the server’s public key and is signed by a trusted certificate authority.
- The client browser verifies the certificate. It checks the CA’s signature, confirms the certificate hasn’t expired or been revoked, and walks the chain of trust up to a root CA it already trusts.
- Client and server negotiate a shared symmetric session key. Using public key cryptography (via RSA key exchange or a Diffie-Hellman variant), they agree on a session key without ever transmitting it in the clear.
- All subsequent data is encrypted symmetrically. The agreed session key and a symmetric algorithm like AES protect the rest of the communication, combining asymmetric security for the handshake with symmetric speed for the data.
TLS 1.3 is the preferred version. NIST guidance sets TLS 1.2 as the minimum acceptable version. TLS 1.0 and 1.1 contain known vulnerabilities and are deprecated; most modern browsers refuse to connect over those older versions entirely.
Real-world use cases for public key encryption
Asymmetric cryptography shows up across a wide range of applications beyond the browser.
- Encrypted email (S/MIME and PGP). The sender encrypts the message with the recipient’s public key, so only the intended recipient can read it. PGP uses a web-of-trust model rather than centralized CAs, while S/MIME relies on traditional PKI.
- SSH authentication. Remote server login uses key pairs instead of passwords. Your private key stays on your local machine; the server holds your public key. Authentication happens without ever transmitting a credential an attacker could reuse.
- Digital certificates. PKI binds public keys to verified identities, letting browsers, email clients, and operating systems confirm they’re communicating with the right party.
- Blockchain and cryptocurrency. Private keys sign transactions; public keys serve as wallet addresses for verification. We cover this in more detail in the next section.
- Cloud key management (envelope encryption). Cloud services wrap symmetric data-encryption keys with a public key, so the symmetric key itself can be stored or transmitted safely. This scales key distribution without requiring each service to hold the master key.
- Document signing. Digital signatures on contracts, invoices, and regulatory filings provide authenticity, integrity, and legal non-repudiation.
- DNSSEC. Digital signatures applied to DNS records prevent spoofing and cache poisoning. When your browser looks up a domain, DNSSEC lets it verify that the DNS response hasn’t been tampered with, closing an attack vector that traditional DNS leaves wide open.
Blockchain and cryptocurrency applications
In crypto, your private key is your identity and your access control rolled into one. It authorizes every transaction leaving your wallet. Your public key (or a hashed version of it) functions as your wallet address, the identifier others use to send you assets and verify your transactions on the blockchain.
This setup means losing your private key isn’t like forgetting a password you can reset. It’s permanent loss of access to every asset in that wallet. No exchange, no support team, no recovery phrase can regenerate the key itself. Most wallet security questions trace back to this single point: understanding key management is directly relevant to safely holding and transferring your crypto assets. Hardware wallets, seed phrase backups, and careful crypto wallet security practices all exist to protect that private key from loss or theft.
Key management best practices
The strength of any encryption system depends not just on the algorithm and key length, but on how carefully the keys themselves are managed.
- Separate key storage from encrypted data. Keys stored on the same server as the encrypted data create a single point of compromise. An attacker who breaches that server gets both the lock and the key.
- Rotate keys on a regular schedule. Even if a key hasn’t been compromised, rotation limits the window of exposure. If a key is eventually broken or leaked, only data encrypted during that key’s active period is at risk.
- Store private keys in hardware security modules (HSMs). HSMs are purpose-built devices that perform cryptographic operations internally without ever exposing the raw key material. Even if the server hosting the HSM is compromised, the private key can’t be extracted.
- Document and verify key destruction procedures. When a key reaches end of life, destroying it thoroughly (and proving it was destroyed) prevents it from resurfacing later. Incomplete destruction is a real audit finding.
- Meet compliance framework requirements. Frameworks like CMMC and FedRAMP examine key generation, storage, rotation, and destruction, not just which algorithm you picked. FIPS 140-3 is the current federal standard for cryptographic module validation, superseding FIPS 140-2. If your systems need to meet federal requirements, the module handling your keys needs to be validated against that standard.
Post-quantum cryptography and future readiness
Quantum computers pose a specific, well-understood threat to RSA and ECC. Both algorithm families derive their security from mathematical problems (integer factorization for RSA, discrete logarithms for ECC) that classical computers can’t solve efficiently. Quantum computers running Shor’s algorithm can solve both of those problems in polynomial time, which would make current key lengths irrelevant regardless of how long they are.
This isn’t a theoretical curiosity. The threat model is concrete enough that organizations are starting migration planning now, before large-scale quantum hardware is available. The concern is that encrypted data captured today could be stored and decrypted later once a sufficiently powerful quantum computer exists, a strategy sometimes called “harvest now, decrypt later.”
NIST is leading standardization efforts for post-quantum algorithms. The replacement candidates fall into several families, with lattice-based and hash-based algorithms receiving the most attention. Lattice-based schemes rely on the difficulty of finding the shortest vector in a high-dimensional lattice, a problem that remains hard even for quantum computers. Hash-based signature schemes build their security on the properties of cryptographic hash functions, which quantum computing weakens but doesn’t break outright (Grover’s algorithm halves the effective security level, so doubling the hash output size restores it).
For organizations running systems today, the practical step is to take inventory: know which algorithms and key lengths you’re using, where your certificates live, and which vendors support algorithm agility so you can swap in post-quantum algorithms when finalized standards are ready.
Frequently asked questions
Can you decrypt a message with a public key?
Not in the confidentiality sense. If someone encrypted data with your public key, only your private key can decrypt it. However, a public key does decrypt a digital signature. When a sender signs a message with their private key, the recipient uses the sender’s public key to verify that signature, confirming who sent it and that the content hasn’t changed.
What is a cryptographic key?
A cryptographic key is a string of data used by an algorithm to transform plaintext into ciphertext or reverse the process. It works like a password that controls encryption and decryption in cryptocurrency and other systems, but unlike a password you’d type, cryptographic keys are typically long, randomly generated values that algorithms process directly.
Can encryption keys be hacked?
Brute-force attacks are theoretically possible, especially with short key lengths. With current technology, though, proper key length and algorithm choice make brute-forcing computationally infeasible. A 2048-bit RSA key or a 256-bit ECC key would take conventional computers longer than the age of the universe to crack by exhaustive search. Future quantum computers could change that equation for current algorithms, which is why post-quantum cryptography research is underway.
How do public and private keys relate to each other mathematically?
They’re generated together using one-way functions. For RSA, the relationship involves the prime factorization of a large composite number. For ECC, it’s based on elliptic curve math. In both cases, deriving the public key from the private key is straightforward, but reversing the process, computing the private key from the public key, is infeasible with current computing power.
How do AES-256 and public key cryptography work together?
Public key encryption securely delivers a symmetric session key (like an AES-256 key) from one party to another. Once both sides have that session key, AES-256 encrypts the actual data. This hybrid approach combines the security of asymmetric key exchange with the speed of symmetric encryption, which is exactly how TLS connections protect your web traffic.
Public key encryption as the backbone of online trust
Asymmetric cryptography ties together confidentiality, authentication, and data integrity across every major internet protocol. From the TLS handshake loading a webpage to the private key signing a Bitcoin transaction on the network, the same mathematical principles apply.
The hybrid pairing with symmetric encryption is what makes the system practical at scale. Asymmetric algorithms handle the trust problem (verifying identities and exchanging keys safely), while symmetric algorithms handle the speed problem (encrypting gigabytes of data without creating a bottleneck). Neither half works well alone.
Algorithm evolution keeps the framework viable. The shift from RSA toward ECC brought smaller keys and faster operations without sacrificing security. The coming transition to post-quantum algorithms will be larger in scope, but the underlying architecture of public key, private key, certificate authority, and hybrid session remains. The math changes; the pattern holds.
