The first time your browser connects to a bank's website, the two machines share no secret at all, and every packet between them crosses networks neither one controls. Within a few dozen milliseconds they agree on an encryption key that nobody watching the traffic can work out. Asymmetric cryptography is what makes that possible.
On the CompTIA Security+ SY0-801 exam, asymmetric encryption and key exchange sit under objective 1.3, which expects you to pick the right cryptographic solution for a job. This lesson explains public and private keys, the RSA and elliptic curve algorithms and their key sizes, Diffie-Hellman key exchange, forward secrecy, and the hybrid design that real systems use.
Asymmetric encryption uses a key pair where each key undoes the other
In asymmetric cryptography, also called public key cryptography, each party has a key pair. The public key can be shared with anyone: published on a website, embedded in a certificate, attached to an email. The private key never leaves its owner's control. The two keys are mathematically linked, so what one key does, only the other key can undo.
Knowing the public key doesn't let anyone compute the private key, because that would mean solving a problem believed to be infeasible at real key sizes. RSA depends on the difficulty of factoring a huge number into its two prime factors. Diffie-Hellman and elliptic curve cryptography depend on the difficulty of computing discrete logarithms.
Which key you use depends on the goal, and this is the point scenario questions on this topic most often turn on:
| Goal | Sender uses | Receiver uses |
|---|---|---|
| Confidentiality: only Bob can read it | Bob's public key to encrypt | Bob's private key to decrypt |
| Authenticity: prove Alice sent it | Alice's private key to sign | Alice's public key to verify |
Confidentiality always uses the recipient's key pair, and signatures always use the sender's. Encrypting something with your own private key provides no secrecy, because everyone has your public key. Digital signatures are covered in the hashing and signatures section, and how you know a public key really belongs to Bob is the job of certificates, covered in the PKI section.
Key pairs also fix the scaling problem from the last lesson. A 1,000-person organization needs 1,000 key pairs instead of 499,500 shared secrets. The price is speed: asymmetric operations are far slower than symmetric ones.
RSA relies on factoring and needs long keys
RSA was published in 1977 by Ron Rivest, Adi Shamir and Leonard Adleman. To create a key pair, software picks two large random primes and multiplies them to get the modulus. The public key is that modulus plus a small public exponent, almost always 65,537. The private key is derived from the two primes. Anyone who could factor the modulus back into its primes could rebuild the private key, and a 2048-bit modulus is a 617-digit number.
Factoring records show where the line is. Researchers factored a 768-bit RSA number in 2009 and an 829-bit number in 2020, each needing roughly 2,000 or more core-years of computing. Keys of 1024 bits are no longer considered safe, and public certificate authorities stopped issuing them over a decade ago. Current guidance is 2048 bits at minimum and 3072 bits or more for keys that must stay secure beyond 2030. Root CA keys are commonly 4096 bits.
RSA is slow, and longer keys make it slower: a private-key operation with a 3072-bit key takes roughly three times as long as with a 2048-bit key. RSA also can't encrypt anything larger than its key. With OAEP padding and SHA-256, a 2048-bit key can encrypt at most 190 bytes, enough for an AES key but nowhere near a file. So RSA does two jobs: signatures, such as on certificates and signed code, and key transport, which means encrypting a symmetric key for someone. It is not used to encrypt bulk data.