Public-key cryptography uses a related public key and private key. The public key can be distributed. The private key must remain under the owner's control.
The part learners often mix up is that the same key pair can support different jobs. The correct key depends on whether the scenario is about confidentiality, signing, verification, or key establishment.
Fast rule: For confidentiality, protect data for the recipient with the recipient's public key. For a digital signature, the signer uses the signer's private key and everyone else verifies with the signer's public key.
1. The fast rule
Keep the owner of the key pair in view.
| Job | Key used first | Matching key used next |
|---|---|---|
| Protect data so only Bob can recover it | Bob's public key | Bob's private key decrypts |
| Alice signs data | Alice's private key | Alice's public key verifies |
| Verify Alice's signature | Alice's public key | Confirms a signature made with Alice's corresponding private key |
| Establish shared key material | Depends on the algorithm/protocol | Do not force an encryption/signature rule onto every key-agreement method |
Two different people may be involved in one scenario, so phrases such as “the public key” are not enough. Ask whose public or private key the question means.
2. Keys for confidentiality
When asymmetric encryption is used to protect information for a recipient:
- The sender obtains the recipient's public key.
- The sender encrypts the protected value with that public key.
- The recipient uses the corresponding private key to decrypt it.
The security goal is confidentiality. Publishing the recipient's public key is expected. The private key is what must remain secret.
Why not encrypt with the sender's private key?
That phrase is a common learning shortcut for signatures, but it is a poor way to reason about confidentiality. A public key is public. If data could simply be recovered with the sender's public key, it would not be confidential.
For Security+ questions, separate these ideas:
- Encrypt for a recipient: recipient's public key → recipient's private key
- Sign as a sender: sender's private key → sender's public key verifies
Real systems are usually hybrid
Asymmetric cryptography is computationally expensive compared with symmetric encryption. Secure protocols commonly use asymmetric mechanisms for authentication or key establishment, then use a symmetric session key to protect the bulk data.
If the question mentions a large file or a long network session, look for the role of the asymmetric operation rather than assuming every byte is encrypted directly with RSA or another public-key algorithm.
3. Keys for digital signatures
A digital signature is created with the signer's private key and verified with the corresponding public key.
A properly implemented signature supports:
- integrity checking
- authentication of the claimed signer when the public key is trusted
- support for non-repudiation
A signature does not make the content secret. Signed material can remain readable unless it is separately encrypted.
Think “prove control,” not “hide data”
The signer proves control of the private key by generating a valid signature. A verifier checks that signature with the public key.
That leads to a useful question clue:
“Which key should a customer use to verify that the software package was signed by the vendor?”
Use the vendor's public key.
The customer should not possess the vendor's private signing key.
4. Where certificates fit
A public key by itself is just a key. A verifier also needs a trustworthy way to associate that key with an identity.
A public-key certificate binds an identifier to a public key and is digitally signed by a certificate authority (CA). The certificate can also contain information such as:
- issuer
- subject or subject alternative names
- public key
- validity period
- allowed key usages
- CA signature
The subject's private key is not included in the certificate.
If an attacker obtained the private key simply by downloading a certificate, public-key infrastructure would collapse rather quickly.
Certificate validation is about the binding
When a browser validates a server certificate, it is not asking only:
“Is this public key mathematically valid?”
It is also evaluating whether the certificate chain leads to a trusted authority, whether the certificate is valid for the expected identity and use, whether it is within its validity period, and whether relevant revocation information indicates a problem.
The certificate helps establish trust in the public-key binding. The private key remains with the entity that proves possession of it during the protocol.
5. Key establishment
Not every asymmetric algorithm works by encrypting with one key and decrypting with the other.
Public-key cryptography can also participate in key agreement or key transport. The result is commonly symmetric key material used for the session.
This matters for exam questions involving protocols such as Transport Layer Security (TLS):
- the certificate can authenticate an endpoint's public key
- an asymmetric exchange can help establish shared key material
- symmetric encryption then protects application traffic efficiently
Avoid memorizing one universal “public encrypts, private decrypts” rule and applying it to every asymmetric algorithm.
6. Common exam traps
Trap: confusing confidentiality with authenticity
“Only the recipient should read it” points to the recipient's key pair.
“Prove who signed it” points to the signer's key pair.
Trap: choosing the sender's public key to encrypt for the recipient
The sender's public key belongs to the wrong person. Encrypting for Bob requires Bob's public key.
Trap: putting the private key in the certificate
Certificates distribute public-key information and identity bindings. Private keys stay private.
Trap: treating a signature as encryption
A signature can prove integrity and origin. It does not conceal the message.
Trap: assuming every asymmetric algorithm supports encryption and signatures
Algorithms have different purposes. Read the protocol or operation described instead of mapping every key pair to RSA-style operations.
7. Rapid review grid
| Scenario clue | Think |
|---|---|
| “Send confidential data to Bob” | Encrypt using Bob's public key |
| “Bob opens confidential data sent to him” | Bob's private key |
| “Alice signs the message” | Alice's private key |
| “Verify Alice's signature” | Alice's public key |
| “What does the certificate contain?” | Identity information + public key + CA signature |
| “Where is the subject's private key?” | Kept separately under the subject's control |
| “Bulk session encryption” | Usually symmetric after key establishment |
| “Key agreement” | Follow the specified algorithm/protocol, not a memorized encrypt/decrypt slogan |
8. Review checklist
Before answering an asymmetric-key question, ask:
- What is the security goal: confidentiality, signature, verification, or key establishment?
- Whose key pair is involved?
- Does the scenario require a public key that can be distributed or a private key that must remain controlled?
- Is a certificate being used to bind identity to a public key?
- Is the question describing a protocol that combines asymmetric and symmetric cryptography?