- Home
- Courses
- Edexcel International A-Level Computer Science
- Encryption Foundations
- Encryption Goals and Key Models
Encryption Goals and Key Models
State what must remain confidential and who is allowed to recover it. Follow the key-distribution path as carefully as the encrypted-message path.
Before you start
- Identify plaintext, ciphertext and the secret information each participant retains.
- Separate intended-recipient identity from possession of an arbitrary public key.
Watch, pause, try
Video by Craig'n'Dave. Use the shared AQA main explanation for symmetric/asymmetric roles and its companion for certificates and signatures. The written Pearson lesson and primary authenticated-encryption reference supply the trust boundaries: an available public key still needs an authenticated owner binding, and encryption, signatures and access permissions solve different requirements.
Viewing focus: Explain plaintext, ciphertext, algorithms and keys
After watching, attempt these questions before opening the answers. You can also use the written lesson below.
After watching 1: A service receives a public encryption key through an unauthenticated message claiming it belongs to a school. It encrypts a private report correctly with that key. Explain what an intermediary substituting its own key could undermine, and what must be checked before encryption is treated as protection for the intended recipient.
Show answer and reasoning
Correct encryption protects for the holder of the matching private capability, which could be the intermediary rather than the school. The sender needs a suitable authenticated binding between the key and the intended identity, with the relevant certificate/name/trust checks or another authenticated distribution mechanism. Public availability and a successful encryption operation alone do not establish the recipient.
After watching 2: A journal service uses sound symmetric authenticated encryption for stored files but logs the plaintext entries and key in a broadly readable diagnostic file. Would adding a digital signature to each encrypted file remove that exposure? Identify which boundaries need attention.
Show answer and reasoning
The diagnostic file exposes both content and secret material outside the encrypted-file boundary. A signature addresses a different origin/integrity claim and does not make those logs confidential. Restrict and minimise sensitive logging, protect key access/retention and account permissions, and analyse the whole data path. A strong primitive cannot compensate for publishing the data or key through another permitted path.
What you'll be able to do
- Explain plaintext, ciphertext, algorithms and keys
- Compare symmetric and asymmetric encryption models
- Justify authenticated key distribution and hybrid use
Define the information being protected
Plaintext is the information supplied to encryption, and ciphertext is the encrypted representation. The encryption algorithm uses a key to transform the information; a suitable decryption procedure with the required key recovers it. Public knowledge of an algorithm is compatible with security when the system’s assumptions and secret-key requirements are satisfied. Encoding text as hexadecimal is not encryption.
Confidentiality concerns preventing unauthorised disclosure. Encryption does not automatically establish every other property: a system may also need integrity, origin authentication, access control and protection of decrypted endpoint data. Explain the threat and the boundary. An encrypted file left open on an unlocked account can still be read through that account.
Trace symmetric and asymmetric keys
In a symmetric model, communicating parties use a shared secret, with the required keying material available to both encryption/decryption participants. This can support efficient protection of substantial data, but securely distributing and retaining the secret matters. Sending the key alongside ciphertext through the same exposed channel does not protect it from the same observer.
Asymmetric encryption uses a public/private pair: a sender can encrypt appropriately for a recipient using the recipient’s public key, while the recipient retains the private decryption capability. Public does not mean unauthenticated keys are safe to accept from anyone. An attacker could substitute their own public key unless the sender verifies its binding to the intended recipient through a suitable trust mechanism.
Evaluate the complete exchange
A hybrid design can use an appropriate asymmetric or agreement mechanism to establish keying material, then symmetric authenticated encryption for bulk traffic. Do not assume every protocol uses RSA key transport; the companion TLS lesson identifies its version-specific agreement model. Authentication and key establishment must fit the actual protocol rather than a generic diagram that silently changes halfway through.
Compare shared-secret management, computational cost, compromise consequences and the number of communicating parties. Losing a decryption key may prevent legitimate recovery, while exposing it may disclose information within the relevant scheme’s limits. A signature is not simply a universal claim that “private-key encryption provides confidentiality”: signature schemes have a different purpose and verification structure. Use exact terms for what is encrypted, what is signed and what identity is checked.
| Model | Teaching key path | Critical question |
|---|---|---|
| Symmetric | Sender/recipient need appropriate shared secret | How is that secret distributed and protected? |
| Asymmetric encryption | Recipient publishes a verified public key and retains private capability | Does the public key belong to the intended recipient? |
| Hybrid protocol | Establish secret material, then protect bulk traffic symmetrically | Are establishment, authentication and data protection correctly combined? |
Work through the problem
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Example 1A sender uploads ciphertext and its symmetric key into the same publicly readable folder. Explain the confidentiality problem.
Example 2A peer supplies a public key and says it belongs to the intended recipient. What is still missing?
Common mistakes to avoid
Key takeaways
- Algorithms, keys and protected data have different roles.
- Shared and public/private models have different distribution problems.
- Evaluate the complete authenticated exchange.
Explore further
- Pearson YCP01 official specification (opens in a new tab)
Check the International A-level requirements and relevant numbered points; this course remains in progress.
- Pearson International Computer Science subject guide (opens in a new tab)
Official introduction to the four examined units and their theory/practical purposes.
- Topic reading and reference (opens in a new tab)
Use the relevant board requirement or primary technical reference alongside the written examples.
- 143. AQA A Level (7517) SLR21 - 4.9.3 Symmetric and asymmetric encryption — Craig'n'Dave (opens in a new tab)
Original publisher or creator source for the embedded explanation; apply the stated viewing scope.
- 144. AQA A Level (7517) SLR21 - 4.9.3 Digital certificates and signatures — Craig'n'Dave (opens in a new tab)
Companion explanation: connect its topic to the written Pearson scope and follow-up activities.
Return to this tomorrow
Close the notes and answer from memory. Revisit any explanation you cannot yet reconstruct.
- Before using a recipient’s public encryption key, verify:
- A hybrid protocol typically combines mechanisms to:
Test yourself
Answer a few questions, then review anything you missed.
Keep practising
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.