Lab: Encrypt & Sign a Message with RSA Key Pairs

About This Activity

You and a partner will use real cryptography — the same RSA public-key math that protects websites, email, and messaging — to send each other a secret message that only the intended person can read, and to prove who really sent it.

Work through the three steps below. Each of you is on your own device; you'll trade public keys and encrypted messages back and forth, while carefully guarding your private key.

👥 Pairs ⏱️ ~20–30 minutes 💻 2 devices 🔐 Real 2048-bit RSA 📘 AP Cyber Unit 5.4

The Three Steps

Complete them in order. Both partners do all three.

1

Generate Keys

Create your own key pair. Keep the private key; share the public key with your partner.

Start Step 1 →

2

Encrypt & Sign

Lock a message with your partner's public key and sign it with your private key.

Go to Step 2 →

3

Decrypt & Verify

Unlock your partner's message with your private key and verify their signature.

Go to Step 3 →

Begin the Activity →

Teacher's Guide For Educators▾

CourseAP Cybersecurity

Unit 5Securing Applications & Data

Topic 5.4Asymmetric Cryptography

SkillMitigate Risk

GroupingPairs · ~20–30 min

Overview

This activity makes public-key cryptography concrete. Rather than reading about RSA, students generate live 2048-bit key pairs in the browser, exchange public keys, and send each other a message that is both confidential (encrypted) and authenticated (digitally signed). It is a hands-on companion to the OpenSSL work in Topic 5.4 — the browser's Web Crypto API stands in for openssl genrsa / pkeyutl, letting students see the encryption direction and signature check that the CED asks them to reason about.

Learning Objectives (AP Cybersecurity CED)

Objectives below are aligned to Unit 5, Topic 5.4 (Asymmetric Cryptography). Essential-knowledge statements are paraphrased for brevity — confirm exact wording against your current official CED.

LO 5.4.A Explain how an asymmetric key pair enables secure communication.

5.4.A.1 — Asymmetric encryption allows secure communication without pre-arranging a shared secret key.
5.4.A.2 — A key pair is generated together as mathematical inverses; one key is designated public and one private, and only the partner key can undo what the other did.
5.4.A.3 — If a private key is compromised, the correct response is to delete the entire key pair and generate a new one.
5.4.A.4 — To send confidentially, the sender encrypts with the receiver's public key; only the receiver's private key can decrypt.

LO 5.4.B Reason about key length and its effect on security.

5.4.B.1–2 — An n-bit key defines a keyspace of 2ⁿ; brute force averages 2ⁿ⁻¹ attempts.
5.4.B.3–4 — Longer keys give more security at higher computational cost, and recommended lengths rise over time as computing power grows.
5.4.B.5 — Key-length comparisons are only meaningful within the same algorithm (e.g., RSA-2048 vs RSA-4096).

LO 5.4.C Identify and apply common asymmetric algorithms.

5.4.C.1 — RSA and ECC are common asymmetric algorithms, used in digital signatures and certificates.
5.4.C.2–3 — Students interpret and write OpenSSL commands such as genrsa, rsa -pubout, and pkeyutl -encrypt/-decrypt. This activity mirrors those operations visually in the browser.

What Each Step Demonstrates

Step	Students do	Concept demonstrated	CED link
1 · Generate	Create a 2048-bit key pair; keep the private key, share the public key.	Keys are born as a pair and are mathematical inverses. The public key can be shared openly; the private key must be protected — the whole security model rests on this asymmetry.	5.4.A.1–.3, 5.4.B
2 · Encrypt & Sign	Encrypt a message with the partner's public key; sign it with their own private key.	Encryption direction: you lock with the receiver's public key so only they can open it. Signing with your own private key proves authorship and integrity.	5.4.A.4, 5.4.C.1
3 · Decrypt & Verify	Decrypt with their own private key; verify the signature with the partner's public key.	Only the matching private key decrypts. Verifying the signature with the sender's public key confirms authenticity — and a tampered or wrongly-signed message fails the check.	5.4.A.4, 5.4.C.1

Facilitation Notes

Before you start

Put students in pairs, each at their own device. Any modern browser works; nothing is installed and no data leaves the machine — all crypto runs locally.
Decide how partners will exchange text (public keys and encrypted messages): a shared doc, chat channel, email, or even copying to a neighboring computer. Keys and messages are long, so copy/paste beats retyping.

The exchange loop

Both partners complete Step 1 and trade public keys.
Each partner uses Step 2 to send the other a message, then pastes the encrypted result to their partner.
Each partner uses Step 3 to open and verify the message they received.

Watch for

Sharing the wrong key. Students sometimes share their private key by mistake — a perfect teachable moment for 5.4.A.3. If it happens, have them regenerate.
Wrong-key errors. Trying to decrypt with the wrong private key fails on purpose. Ask why before helping.
Tampering. Have a pair change one character of an encrypted message before Step 3 to see decryption/verification fail — this shows integrity protection in action.

Discussion Questions

Why can you post your public key anywhere, but never share your private key? (5.4.A.1–.2)
Whose key do you use to encrypt a message, and whose key decrypts it? Why that direction? (5.4.A.4)
How does a digital signature prove who sent a message — and what happens to the signature check if even one character is altered? (5.4.C.1)
If your private key is exposed, why isn't it enough to just "change your password"? What must you do instead? (5.4.A.3)
This demo uses a 2048-bit key. What are the trade-offs of going to 4096 bits, and why do recommended key lengths keep rising? (5.4.B)

Extension & Assessment Ideas

Have students reproduce Step 1–3 with the real OpenSSL commands from 5.4.C and compare the outputs to the browser version.
Exit ticket: given a scenario ("Ana wants to send Ben a private message"), students state which key encrypts, which decrypts, and which signs/verifies.
Connect to Unit 5.6 (detecting data attacks): the signature check here is the same idea as verifying a file's hash to detect tampering.

The learning-objective and essential-knowledge codes above are aligned to the AP Cybersecurity Course and Exam Description (Unit 5: Securing Applications and Data, Topic 5.4). The official College Board CED is the authoritative source — verify exact codes and wording against your current edition. AP and Advanced Placement are trademarks of the College Board, which is not affiliated with and does not endorse this activity.

👥 Paired activity — you and your partner each work on your own device. Here in Step 1 you both generate your own keys, then swap public keys with each other.

Step 1: Generate Your Key Pair

How Asymmetric Encryption Works

Think of it like a locked mailbox:

Public Key = The mail slot. Anyone can drop a message in, but they can't open the box to read what's inside.
Private Key = The key to the mailbox. Only you can open it and read the messages.

You generate both keys together as a pair. Share your public key freely — but never share your private key.

Click to create a real 2048-bit RSA key pair in your browser.

👥 Paired activity — write a secret message to your partner. You'll lock it with the public key they shared with you, then send them the result.

Step 2: Encrypt & Sign a Message

What Happens in This Step

🔒 Encrypt — You use your partner's public key to lock the message so only they can read it.
✍️ Sign — You use your own private key to add a digital signature, proving the message is from you.

Partner's Public Key

Paste the public key your partner shared with you.

Your Private Key

Used to sign the message so your partner knows it's really from you.

Your Secret Message

0/150 characters

🔐 Encrypted & Signed Message

Copy this and send it to your partner. Only their private key can decrypt it, and your signature proves it's from you.

← Back to Step 1 Continue to Step 3 →

👥 Paired activity — open the message your partner sent you. Unlock it with your own private key, then use their public key to confirm they really sent it.

Step 3: Decrypt & Verify

What Happens in This Step

🔓 Decrypt — You use your own private key to unlock and read the message. Only you can do this.
🛡️ Verify — You use your partner's public key to confirm the signature. This proves the message really came from them and wasn't altered.

Your Private Key

Used to decrypt the message that was locked with your public key.

Partner's Public Key (for verification)

Used to check the signature and confirm the message really came from your partner.

Encrypted Message from Partner

Paste the encrypted message your partner sent you.

📨 Decrypted Message

← Back to Step 2 Start Over ↻