CS12 — Encryption: public and private keys, digital certificates and signatures
- I can explain the difference between symmetric and asymmetric encryption.
- I can describe how a public/private key pair is used to encrypt and decrypt data.
- I can explain what a digital certificate contains and what it proves.
- I can explain how a digital signature is created and verified.
- I can state that data encrypted with a public key can only be decrypted with the matching private key.
- I can explain that a digital certificate links a public key to an identity, verified by a Certificate Authority.
- I can explain that a digital signature proves a message came from the claimed sender and has not been altered.
- I can describe a real context (e.g. HTTPS) where asymmetric encryption, certificates and signatures are used together.
Key vocabulary
Why encryption matters
Every time you log in to a website, make an online payment, or send a message, data travels across the internet. Without protection, anyone in a position to intercept that traffic could read usernames, passwords, and financial details in plaintext. Encryption transforms data so that even if it is intercepted, it appears as meaningless characters to anyone who does not hold the correct key.
Encryption is not a single technique — there are different approaches, each with trade-offs between speed, security, and practicality. The two most important categories for Higher Computing Science are symmetric encryption and asymmetric encryption.
Symmetric encryption and its limitation
In symmetric encryption, the same key is used to both encrypt and decrypt data. This is fast and efficient, making it suitable for encrypting large amounts of data. The problem arises at the start of communication: how do two parties who have never met share the secret key securely? If Alice wants to send Bob the key over the internet, and an attacker intercepts it, the attacker can decrypt every future message. There is no safe way to exchange the key without first having a secure channel — which is exactly what you are trying to create.
Asymmetric encryption: public and private keys
Asymmetric encryption solves the key exchange problem by using two mathematically linked keys: a public key and a private key. They are generated as a pair. The critical property is:
- Data encrypted with the public key can only be decrypted with the matching private key.
- Data encrypted with the private key can only be decrypted with the matching public key.
The public key can be shared with anyone — it is designed to be public. The private key must be kept completely secret by its owner. Even knowing the public key, it is computationally infeasible to calculate the matching private key.
This elegantly solves the key exchange problem: Bob can publish his public key for anyone to see. If Alice wants to send Bob a secret message, she encrypts it with Bob's public key. Only Bob's private key can decrypt it. Even if an attacker intercepts the encrypted message, they cannot decrypt it without Bob's private key.
Asymmetric encryption is slower than symmetric encryption because the mathematics involved is more complex. In practice, systems like HTTPS use asymmetric encryption only to securely exchange a symmetric session key. Once both parties share that key, they switch to faster symmetric encryption for the bulk of the data transfer.
Digital certificates — proving identity
Asymmetric encryption solves the confidentiality problem, but it raises a new question: how does Alice know that the public key she is using actually belongs to Bob, and not to an attacker pretending to be Bob? An attacker could publish their own public key and claim it is Bob's. If Alice encrypts a message with the attacker's public key thinking it is Bob's, the attacker can read it.
A digital certificate solves this by linking a public key to a verified identity. A certificate contains:
- The owner's public key
- The owner's identity (name, organisation, domain name)
- The name of the Certificate Authority that issued it
- An expiry date
- A digital signature from the Certificate Authority
A Certificate Authority (CA) is a trusted organisation — like DigiCert, Let's Encrypt, or GlobalSign — that verifies an organisation's identity and issues certificates. The CA signs each certificate with its own private key. Browsers and operating systems come with a built-in list of trusted CAs. When your browser visits a website, it checks that the website's certificate was signed by a trusted CA. If the signature is valid and the certificate has not expired, the browser knows the public key in the certificate genuinely belongs to the claimed domain.
This is why your browser shows a padlock icon for secure websites — it has successfully validated the digital certificate.
Digital signatures — proving authenticity and integrity
A digital signature serves a different purpose from encryption. While encryption keeps data secret, a digital signature proves two things:
- Authenticity: the message came from who it claims to be from.
- Integrity: the message has not been altered since it was signed.
A digital signature is created using the sender's private key and verified using the sender's public key. The process works in two stages:
The key insight is that only the sender could have created the signature, because only they hold their private key. Anyone can verify it using the freely available public key. If even one character in the message is changed after signing, the hash will be completely different, so the hashes will not match and the verification fails.
Digital signatures are used to verify software updates, email authenticity, legal documents, and the certificates issued by Certificate Authorities themselves.
How these concepts combine in HTTPS
When you visit a website using HTTPS, all three concepts work together:
- Your browser receives the website's digital certificate and verifies it against a trusted CA.
- If valid, the browser uses the website's public key (from the certificate) to encrypt a randomly generated symmetric session key.
- Only the website's private key can decrypt this, so only the genuine website can read it.
- Both sides now share the session key and switch to faster symmetric encryption for the rest of the session.
- Digital signatures on messages in the exchange confirm they have not been tampered with in transit.
This combination gives confidentiality (nobody else can read the data), authentication (you know you are talking to the genuine website), and integrity (data has not been modified in transit).
Worked examples
A user wants to download a software update. The developer has digitally signed the update file. Explain how the user can verify the update is genuine and has not been tampered with.
The developer calculates a hash of the update file and encrypts it with their private key to create a digital signature. The user's computer downloads both the update and the signature. Using the developer's public key, the computer decrypts the signature to recover the original hash. It then calculates a hash of the downloaded file itself. If both hashes match, the file is genuine (only the developer could have created the signature) and unaltered (any tampering would produce a different hash).
- Do not say you encrypt with the private key to send a secret message. For confidentiality, you encrypt with the recipient's public key. The private key is used to decrypt, or to sign.
- Do not say the public key must be kept secret. It is designed to be shared openly — that is what makes the system work.
- Do not confuse digital signatures with encryption. A signature proves authenticity and integrity; it does not make the message confidential.
- Do not say a digital certificate "encrypts" data. A certificate links a public key to an identity — it does not itself encrypt anything.
- Avoid saying "the CA keeps data safe". The CA verifies identity and issues certificates; it is not involved in the encryption of messages.
When explaining asymmetric encryption, always state which key does what: "the public key encrypts; only the matching private key can decrypt." When explaining digital signatures, state the direction: "signed with the private key, verified with the public key." Knowing the direction of key use is what earns marks — a vague answer about "keys" will not.
Task Set A — Core questions
Higher Computing Science → Computer Systems → CS12
Suggested timing: 5 min warm up · 10 min vocabulary · 30 min notes with diagram discussion · 10 min worked examples · 5 min now-you-try · 25 min task set · 5 min review.
Key diagram to draw on the board: Alice → (Bob's public key) → ciphertext → (Bob's private key) → Bob. Pupils consistently confuse which key does what, so a visual drill here pays dividends.
Common misconception to address: "The public key must be kept secret." It must not — it is designed to be shared. The word "public" is the clue. Spend a moment on this explicitly.
Asymmetric vs symmetric distinction: The key exam distinction is not just what they are but when they are used: asymmetric for key exchange and authentication; symmetric for bulk data. HTTPS uses both.
SQA command words covered: explain, describe, give an example.
Link to CS10/CS11: Remind pupils that the Computer Misuse Act covers unauthorised access to encrypted data. Encryption is a technical control that complements legal controls.
Privacy note: Use only generic examples. Do not discuss real security incidents involving identifiable organisations in a way that might be distressing or misleading.