PKI, or Public Key Infrastructure, is built on asymmetric encryption. It uses a pair of mathematically linked keys, one public and one private, to encrypt data, verify identities, and establish trust online. But the full picture is more nuanced: in practice, PKI almost always works alongside symmetric encryption to handle the heavy lifting of actual data transfer.
Why PKI Is Classified as Asymmetric
Symmetric encryption uses a single shared key for both locking and unlocking data. If you and a colleague both know the same password, that’s the symmetric model. Asymmetric encryption splits the job into two keys: a public key that anyone can see and a private key that only the owner holds. Data encrypted with the public key can only be decrypted with the matching private key, and vice versa.
PKI is the entire system of trust built around this asymmetric key pair. It includes the keys themselves, the digital certificates that tie those keys to a verified identity, and the organizations that issue and manage those certificates. Every piece of this infrastructure depends on the two-key model, which is why PKI is fundamentally asymmetric.
How the Two Keys Work Together
The public and private keys serve two main purposes: encryption and digital signatures.
For encryption, someone sends you a message by encrypting it with your public key. Only your private key can decrypt it, so even if the message is intercepted, it’s unreadable to anyone else. For digital signatures, the process reverses. You sign a document using your private key, and anyone with your public key can verify the signature is genuinely yours. This confirms both who sent the message and that nobody tampered with it in transit.
This two-key system solves a problem that symmetric encryption can’t easily handle: how do two strangers securely agree on a shared secret without meeting in person? With asymmetric encryption, you can publish your public key openly. There’s no secret to protect during the exchange.
PKI Uses Symmetric Encryption Too
Asymmetric encryption is computationally expensive. Encrypting a large file or streaming video with a public/private key pair would be painfully slow. Symmetric encryption, by contrast, is fast and efficient. So most real-world systems use both, in what’s called a hybrid approach.
Here’s how it works in practice: when your browser connects to a website over HTTPS, PKI handles the initial handshake using asymmetric encryption. Once both sides have verified each other’s identity and agreed on a shared secret, they generate symmetric session keys. All the actual data, the web pages, images, form submissions, flows back and forth using those fast symmetric keys. The asymmetric part of PKI is finished in milliseconds, and symmetric encryption takes over for the rest of the session.
What Happens During a TLS Handshake
The TLS handshake is where you can see this hybrid model play out step by step. When you visit a secure website, your browser and the server go through a rapid negotiation:
- Client hello: Your browser sends a message listing the encryption methods it supports, along with a random number.
- Server hello: The server responds with its digital certificate (containing its public key), its chosen encryption method, and its own random number.
- Key exchange: Both sides use the exchanged information to independently calculate the same “premaster secret.” In a common method called Diffie-Hellman, neither side ever sends this secret directly. They each arrive at it using shared parameters and their own private values.
- Session keys created: Both sides combine the premaster secret with the random numbers they exchanged earlier to generate identical session keys.
- Symmetric encryption begins: Both sides send a “finished” message encrypted with the new session key, confirming everything matches. From this point on, all communication uses fast symmetric encryption.
The entire handshake typically completes in under a second. Asymmetric cryptography secures the setup, and symmetric cryptography handles the conversation.
The Trust System Behind PKI
PKI isn’t just encryption. It’s a framework for proving that a public key actually belongs to who it claims to belong to. This trust is established through digital certificates and Certificate Authorities (CAs).
A digital certificate is essentially a file that binds a public key to an identity, like a company name or domain. The certificate is digitally signed by a CA, an organization trusted to verify identities before issuing certificates. That CA’s own certificate was signed by another CA above it, forming a chain. At the top sits a root CA, whose certificate is pre-installed in your browser or operating system. When your browser checks a website’s certificate, it follows this chain upward until it reaches a root it already trusts.
Certificates can also be revoked if a private key is compromised or an organization’s identity changes. Two common methods handle this. Certificate Revocation Lists (CRLs) are downloadable lists of revoked certificate serial numbers that your browser checks against. The Online Certificate Status Protocol (OCSP) is a faster, more targeted approach where your browser asks a server about one specific certificate and gets back a status of “good,” “revoked,” or “unknown.” CRLs can lag behind by hours since they aren’t always published immediately after a revocation. OCSP provides more current information but requires a live query for each certificate check.
Current Key Length Standards
The security of asymmetric encryption depends heavily on key length. Longer keys are harder to crack but slower to process. The National Institute of Standards and Technology (NIST) currently recommends RSA keys of at least 3,072 bits for long-term security, providing 128 bits of security strength. Keys between 2,048 and 3,072 bits are acceptable through the end of 2030 but are considered transitional.
Elliptic Curve Cryptography (ECC) achieves comparable security with much shorter keys. A 256-bit elliptic curve key provides roughly the same protection as a 3,072-bit RSA key, which makes ECC popular on devices with limited processing power, like phones and IoT sensors. For use cases that need only 112 bits of security, curves with key lengths as short as 224 bits remain acceptable through 2030.
These numbers matter because they shape the trade-off between speed and protection. Larger keys mean stronger security but slower handshakes. The trend across the industry is toward ECC because it delivers strong security without the performance cost of very large RSA keys.
Symmetric vs. Asymmetric: A Quick Comparison
- Number of keys: Symmetric uses one shared key. Asymmetric uses a public/private pair.
- Speed: Symmetric is significantly faster, making it better for bulk data.
- Key distribution: Symmetric requires both sides to securely share the same key. Asymmetric lets you publish the public key openly.
- Role in PKI: Asymmetric encryption establishes identity and trust. Symmetric encryption handles the ongoing data transfer.
PKI is asymmetric at its core, but its real-world power comes from combining both types. Asymmetric encryption solves the trust problem, and symmetric encryption solves the speed problem. Together, they’re what makes secure browsing, encrypted email, VPNs, and code signing practical at scale.