AP® Cybersecurity · Unit 5: Securing Applications and Data · Topic 5.4
Asymmetric Cryptography
Asymmetric cryptography uses a related public key and private key to solve a difficult trust problem: people and systems can protect keys, verify signatures, and authenticate across an untrusted network without first sharing the same long-term secret.
One key pair, two different responsibilities
Asymmetric cryptography, also called public-key cryptography, uses a mathematically related key pair. The public key can be distributed. The corresponding private key must remain under the owner’s control. Knowing a valid public key should not make it practical to calculate the private key when an approved algorithm, parameters, and implementation are used correctly.
Designed for distribution
Depending on the algorithm and protocol, it can verify the owner’s digital signature, help encrypt or wrap a key for the owner, or participate in establishing a shared secret. It is not a password.
Designed for controlled use
It can create signatures, decrypt suitable ciphertext, or help derive a shared secret. Its exact operation depends on the scheme. Exposure can enable impersonation, decryption, or both.
Key-pair notation: (Kpub, Kpriv). The pair is related, but the public key should not reveal the private key within the intended security assumptions.
Conceptual confidentiality flow
Conceptual encryption: C = EKpub,B(P) and P = DKpriv,B(C). In practice, modern systems usually use public-key methods to protect or establish a short symmetric key, then encrypt bulk data symmetrically.
Symmetric versus asymmetric cryptography
| Feature | Symmetric | Asymmetric |
|---|---|---|
| Key structure | One shared secret key performs a cryptographic operation and its inverse, such as encryption and decryption. | A related public-private pair performs complementary operations. |
| Distribution problem | Authorized parties need a secure way to share or access the secret key. | The public key can be distributed, but its identity binding must be verified and the private key must stay controlled. |
| Performance | Fast and efficient for large files, storage, and high-volume session traffic. | Slower and more computationally expensive; best for signatures and key establishment rather than bulk data. |
| Typical services | Bulk confidentiality and authenticated encryption using a shared session key. | Digital signatures, identity authentication, key agreement, key transport or wrapping, and trust establishment. |
| Common combination | A hybrid protocol authenticates parties and establishes a fresh symmetric session key asymmetrically, then protects most data with fast symmetric authenticated encryption. | |
Digital signatures: prove origin and detect change
A digital signature is generated using the signer’s private key and verified with the corresponding public key. Signature algorithms normally process a cryptographic digest of the message as part of a defined signing scheme. If the message changes, verification should fail.
Conceptual signature: S = SignKpriv,A(H(m)); VerifyKpub,A(m, S) returns valid or invalid. Signing is a specialized signature operation—not simply “encrypting with a private key.”
Authenticity
A valid signature supports the claim that an entity controlling the corresponding private key signed the message. The public key must be reliably connected to that identity.
Integrity
Verification detects whether the signed data or signature changed after signing. A valid signature does not make the message confidential.
Nonrepudiation
A signature can provide evidence to a third party, especially when key custody, identity proofing, timestamps, logs, and policy are trustworthy. It is not absolute proof that a specific human personally clicked “sign.”
| Question | Encryption for a recipient | Digital signing by a sender |
|---|---|---|
| Primary goal | Confidentiality: keep content unreadable to unauthorized parties. | Authenticity and integrity: identify the signing key and detect change. |
| Key use | Recipient’s public key protects; recipient’s private key recovers, in a suitable scheme. | Signer’s private key signs; signer’s public key verifies. |
| Who can use the public operation? | Anyone with the authentic recipient public key can protect suitable content for the recipient. | Anyone with the authentic signer public key can verify; verification does not reveal the private key. |
| Can both be used? | Yes. A message can be signed for authenticity and separately encrypted for confidentiality using appropriate protocols and key pairs. | |
PKI and digital certificates create scalable trust
Public key infrastructure (PKI) is the combination of policies, roles, processes, repositories, software, and hardware used to issue, manage, validate, renew, and revoke public-key certificates and key pairs. PKI does not make every certificate trustworthy automatically; it provides a framework for making and checking identity-to-key claims.
Digital certificate
A signed digital document that binds a public key to identity information or another identifier. It commonly includes an issuer, subject or domain names, public key, serial number, validity period, key usage, and CA signature.
Certificate authority
A CA verifies claims according to policy, issues certificates by digitally signing them, and provides revocation information. An intermediate CA may issue end-entity certificates below a trusted root.
Relying party
A browser, application, device, or person that validates a certificate and decides whether to trust the key for a specific purpose. Trust stores contain approved root certificates.
Conceptual certificate-validation checklist
- Identity matchesThe requested website hostname or intended identity appears in the certificate’s approved identity fields.
- Chain is trustedSignatures link the end-entity certificate through any intermediate CAs to a trusted root, and constraints are satisfied.
- Time and use fitThe certificate is within its validity period and permitted for the intended key usage and protocol purpose.
- Status and policy passThe certificate has not been revoked according to the applicable status mechanism, algorithms remain acceptable, and local policy approves it.
How public-key cryptography supports everyday security
HTTPS and secure websites
During TLS setup, a site certificate helps authenticate the server. Public-key key establishment helps create fresh shared secrets; symmetric authenticated encryption then protects the high-volume web session.
Secure messaging and email
A sender can encrypt a data key for recipients and sign a message. Email systems may use certificate-based PKI or another trust model. Metadata and endpoint security still matter.
Authentication
A service can send a challenge that a device signs with its private key. The service verifies it using the registered public key, proving key possession without transmitting the private key.
Software and update signing
A publisher signs software or a release manifest. Devices verify the signature before installation, helping detect unauthorized changes and identify the signing source.
Cloud services
Certificates authenticate service endpoints, signed tokens or requests support workload identity, and managed key services protect private keys used by applications and automation.
Secure key exchange
Key agreement allows parties to derive shared symmetric keying material. Authentication must be included so an unknown intermediary cannot silently establish separate keys with both sides.
Hybrid session pattern: authenticate endpoint + establish fresh shared secret + derive session keys + protect application data with symmetric authenticated encryption.
RSA, elliptic-curve cryptography, and responsible choices
RSA
RSA security is based on the difficulty of integer factorization under suitable assumptions. Defined RSA schemes can support signatures and key establishment or transport. Secure use requires approved key sizes, randomized padding or encoding schemes, careful implementation, and separate keys or purposes where policy requires.
Elliptic-curve cryptography (ECC)
ECC uses mathematical groups based on elliptic curves. Different ECC schemes support signatures or key agreement; “ECC” is a family, not one operation. ECC often offers smaller keys and efficient communication for comparable classical security, but curves, parameters, validation, and implementations must be approved.
Algorithm names alone do not guarantee security. Organizations must choose approved schemes and parameters for the purpose, use maintained cryptographic libraries, validate keys and certificates, generate strong randomness, protect implementations from side channels, inventory cryptographic use, and plan migrations as standards evolve.
Benefits
- No need to distribute a private key
- Scalable identity and certificate trust
- Digital signatures and key establishment
- Authentication without sending the private key
Limitations
- Slower than symmetric cryptography
- PKI and validation can be complex
- Public keys still need authentic binding
- Revocation and migration require operations
Private-key safeguards
- Generate with approved randomness
- Limit export and permitted operations
- Use secure hardware or key stores
- Apply MFA, approvals, logs, rotation, backup, recovery, revocation, and destruction
Map the security goal to the operation
| Goal | Asymmetric contribution | Required supporting trust |
|---|---|---|
| Confidentiality | Protect a data key for the intended recipient or establish shared session keys. | The recipient public key is authentic and the private key remains protected. |
| Integrity | A digital signature verification fails if signed data changes. | The signature scheme is sound and the verifier uses the authentic public key. |
| Authentication | Proof of private-key possession or a validated signature can authenticate a service, user, device, or message origin. | The public key is reliably bound to the claimed identity and replay is prevented. |
| Nonrepudiation | A signature can provide evidence that a key under the signatory’s control produced it. | Strong identity proofing, exclusive key control, trustworthy timestamps and logs, and applicable policy or legal context. |
Real-world trust decisions
Secure school portal
A browser validates the portal certificate and authenticates the server during TLS setup. The connection derives symmetric session keys, which protect grades and assignments efficiently. A certificate warning is reported rather than bypassed.
Signed software update
A vendor signs an update manifest using a protected release-signing key. Student devices verify the signature with a trusted public key before installation. A valid signature supports source and integrity; vulnerability scanning and patch testing still matter.
Cloud workload identity
A cloud service proves possession of a private key tied to an approved workload identity. Short-lived credentials and least-privileged authorization determine what it can access; HSM-backed key operations and audit logs reduce exposure.
Confidential signed message
A message is signed with the sender’s private signing key and encrypted using a fresh symmetric content key protected for the recipient. The recipient verifies the sender’s certificate and signature after decryption.
Watch: public and private keys
As you watch, separate the confidentiality flow from the signature flow, then identify how the public key becomes trustworthy.
Knowledge check: pair the key with the purpose
What the quiz covers
These 10 questions test public and private keys, confidentiality, signing and verification, symmetric performance, PKI certificates, validation and revocation, hybrid HTTPS sessions, key agreement, and private-key compromise response.
How it works
Answer every question and select Check my score. You will then see one correct answer per question, a concise explanation, your score out of 10, and a restart option.
Study toolkit
For each scenario, ask: Whose key is used? What is the goal? How is the public key authenticated? What happens if the private key is compromised? Continue with this cryptography introduction, explore related computer science resources, or organize revision with these AP® self-study strategies.
Trust anchor
A public key or certificate accepted as a starting point for validating a certificate chain.
Certificate chain
An ordered path from an end-entity certificate through issuing CAs to a trusted root.
Key agreement
A process in which parties contribute information to derive shared secret keying material.
Key transport
A process in which one party selects keying material and securely transfers it to another.
Relying party
An entity that validates and relies on a certificate, key, assertion, or digital signature.
Hybrid cryptography
A design combining public-key trust or key establishment with efficient symmetric protection.
Frequently asked questions
1. What is asymmetric cryptography?
Asymmetric cryptography uses a mathematically related public-private key pair. Depending on the scheme, the pair can support encryption, signatures, authentication, or key establishment without distributing the private key.
2. Why can a public key be shared safely?
Approved public-key schemes are designed so knowing the public key does not make calculating the private key practical under their security assumptions. However, users must still verify that the public key belongs to the claimed owner.
3. Does a digital signature encrypt a message?
No. A digital signature supports authenticity and integrity but normally leaves the message readable. Encryption provides confidentiality. A protocol can sign and encrypt through separate, correctly ordered operations.
4. What is nonrepudiation?
Nonrepudiation is evidence that helps prevent a signatory from credibly denying a valid signature later. Its strength depends on exclusive private-key control, identity proofing, trustworthy timestamps and logs, policy, and legal context.
5. What does a certificate authority do?
A CA validates claims according to policy, issues digitally signed certificates that bind identifiers to public keys, and provides certificate-status or revocation information. A CA must protect its own signing keys carefully.
6. What is checked when validating a website certificate?
Conceptually, a client checks the website identity, signature chain to a trusted root, validity interval, key usage and constraints, revocation status where applicable, algorithm acceptability, and local policy.
7. How do certificate expiration and revocation differ?
Expiration is the scheduled end of a certificate’s validity period. Revocation withdraws trust earlier, often because a key was compromised, a certificate was issued incorrectly, or the subject’s status changed.
8. Why is asymmetric cryptography slower than symmetric cryptography?
Public-key operations use more computationally expensive mathematics and often larger structures. Secure systems therefore use asymmetric cryptography for signatures and key establishment, then symmetric cryptography for bulk data.
9. Are RSA and ECC interchangeable?
No. They are different families with different mathematical foundations, schemes, parameter choices, key formats, and performance characteristics. A protocol and policy must specify an approved algorithm, purpose, parameters, and implementation.
10. What happens if a private key is compromised?
An attacker may impersonate the owner, create signatures, or decrypt suitable protected information, depending on key usage. Stop the key’s use, revoke related certificates, replace the pair, update trust, investigate exposure, and follow the incident plan.
Trusted references
- NIST FIPS 186-5—the Digital Signature Standard.
- NIST SP 800-56A Rev. 3—pair-wise key-establishment schemes using discrete logarithm cryptography.
- NIST Digital Identity Guidelines glossary—public keys, certificates, and PKI terminology.
- NIST CSRC certificate revocation list glossary—certificate revocation concepts.
AP® is a trademark registered by the College Board, which is not affiliated with and does not endorse this page. This lesson is for defensive education. Use approved cryptographic libraries, services, and organizational procedures; never access private keys or protected data without authorization.
