Inquiry Question 1: How are secure systems designed?
Compare symmetric and asymmetric encryption, and describe their roles in securing data in transit and at rest
A focused answer to the HSC Software Engineering Module 1 dot point on encryption. Symmetric (AES) versus asymmetric (RSA), where each is used, how HTTPS combines them, the worked example, and the traps markers look for.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
What this dot point is asking
NESA wants you to compare symmetric and asymmetric encryption on speed, key management, and typical use case, then explain how real systems combine both - especially HTTPS, the most-examined example.
The answer
Symmetric encryption
One shared key is used to encrypt and decrypt. The same key that scrambles the data unscrambles it.
- Algorithm: AES (Advanced Encryption Standard) with key sizes of 128, 192, or 256 bits.
- Speed: very fast, can encrypt gigabytes per second on commodity hardware.
- Key management problem: both parties need the key before they can communicate. Distributing the key securely is the hard part.
- Typical use: encrypting data at rest (databases, files), bulk encryption of session traffic once a session key has been established.
Asymmetric encryption
A key pair: a public key (shared with everyone) and a private key (kept secret by the owner). Data encrypted with the public key can only be decrypted with the private key.
- Algorithm: RSA (typical key size 2048 or 4096 bits), or Elliptic Curve Cryptography (smaller keys, same security).
- Speed: much slower than symmetric, roughly 1000x slower per byte.
- Key management: solves the key exchange problem. You can publish your public key anywhere; only you can decrypt messages sent to it.
- Typical use: key exchange, digital signatures, certificates.
The hybrid model: HTTPS
Real systems combine both. HTTPS is the canonical example: asymmetric encryption for the handshake (key exchange), then symmetric encryption for the bulk traffic. The diagram shows the four-step handshake.
- The browser opens a TCP connection to the server.
- The server sends its TLS certificate, which contains its public key.
- The browser verifies the certificate against a list of trusted certificate authorities.
- The browser generates a random session key (symmetric).
- The browser encrypts the session key with the server's public key and sends it.
- The server decrypts the session key with its private key.
- All subsequent traffic in the session is encrypted with the symmetric session key.
Asymmetric encryption is used only for the handshake. The actual data is protected by fast symmetric encryption.
Worked code
A short Python example using the cryptography library:
from cryptography.fernet import Fernet
# Symmetric: AES under the hood
key = Fernet.generate_key()
cipher = Fernet(key)
message = b"transfer $5000 to account 123"
encrypted = cipher.encrypt(message)
decrypted = cipher.decrypt(encrypted)
assert decrypted == message
For asymmetric:
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()
message = b"session key here"
encrypted = public_key.encrypt(
message,
padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
algorithm=hashes.SHA256(), label=None)
)
decrypted = private_key.decrypt(
encrypted,
padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
algorithm=hashes.SHA256(), label=None)
)
assert decrypted == message
Exam-style practice questions
Practice questions written in the style of NESA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
2025 HSC5 marksCompare symmetric and asymmetric encryption. Explain how HTTPS uses both to secure a connection between a browser and a web server.Show worked answer →
Symmetric encryption uses one shared key for both encryption and decryption. AES-256 is the standard. It is very fast, suitable for encrypting large amounts of data, but both parties need a secure way to exchange the key first.
Asymmetric encryption uses a key pair: a public key that anyone can use to encrypt, and a private key (kept secret) that only the owner can use to decrypt. RSA and Elliptic Curve are common. Asymmetric is much slower than symmetric, so it is not used for bulk data.
HTTPS combines both to get the best of each. When the browser connects to the server:
- The server sends its public key (inside a certificate signed by a trusted authority).
- The browser verifies the certificate, then generates a fresh random symmetric session key.
- The browser encrypts the session key with the server's public key and sends it. Only the server can decrypt it.
- From then on, all traffic in the session is encrypted with the symmetric session key using AES.
The asymmetric step solves the key-exchange problem. The symmetric step gives speed. Markers reward the comparison (speed, key management, use case), the explicit handshake steps, and naming AES and RSA.
Practice questions
Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.
foundation3 marksState whether symmetric or asymmetric encryption is more appropriate for encrypting a 4 GB nightly database backup file stored on the company's own server, and justify your choice.Show worked solution →
Answer: symmetric encryption (AES-256).
The backup is large (4 GB) and both the encrypting and decrypting party are the same organisation, so there is no key-exchange problem to solve. Symmetric encryption is roughly 1000x faster per byte than asymmetric, so it can encrypt gigabytes of data in a practical time. Asymmetric encryption would be far too slow for a file this size and offers no benefit here because no key needs to be exchanged with an external party.
Marking criteria: 1 mark for correctly identifying symmetric/AES, 1 mark for citing speed/data volume as the reason, 1 mark for explaining that no external key exchange is needed.
foundation3 marksA company wants members of the public to be able to email it confidential feedback without first arranging a shared secret. Identify the type of encryption to use and explain why.Show worked solution →
Answer: asymmetric encryption.
The company publishes its public key. Anyone can use it to encrypt a message before sending, without ever having met the company or exchanged a secret key in advance. Only the company, holding the matching private key, can decrypt the messages. This solves the key-exchange problem that symmetric encryption cannot solve on its own, since the public has no safe channel to receive a shared symmetric key through in the first place.
Marking criteria: 1 mark for identifying asymmetric encryption, 1 mark for explaining the public key can be published and used by anyone, 1 mark for linking this to solving the key-exchange problem.
core4 marksThe table below shows the measured throughput for encrypting the same 1 GB file using three approaches on identical server hardware.
| Approach | Throughput |
|---|---|
| AES-256 (symmetric) | 950 MB/s |
| ChaCha20 (symmetric) | 900 MB/s |
| RSA-2048 (asymmetric) | 0.9 MB/s |
Using the table, explain why HTTPS encrypts the bulk of a web session with AES rather than RSA.
Show worked solution →
Reading the table. AES-256 encrypts at 950 MB/s, over 1000 times faster than RSA-2048 at 0.9 MB/s (950 / 0.9 is approximately 1056).
Applying it to HTTPS. A web session can carry many megabytes of page content, images, and API traffic. At RSA's 0.9 MB/s, encrypting even a single 10 MB page would take over 11 seconds, an unacceptable delay. At AES's 950 MB/s, the same page encrypts in about 0.01 seconds. HTTPS therefore uses the slow asymmetric algorithm (RSA or ECC) only once per session, to securely exchange a symmetric session key, then switches to the fast symmetric algorithm (AES) for every subsequent byte of traffic.
Marking criteria: 1 mark for correctly reading/comparing the throughput figures, 1 mark for quantifying the speed difference (~1000x), 1 mark for linking this to the impracticality of using RSA for bulk data, 1 mark for correctly describing the hybrid handshake-then-bulk-transfer pattern.
core4 marksExplain why storing a database's AES encryption key on the same server as the encrypted database weakens the protection that encryption is meant to provide.Show worked solution →
Encryption only protects data if the key stays out of an attacker's reach. If the key is stored on the same server as the encrypted database, then any attacker who successfully breaches that server (for example through a stolen admin password or an unpatched vulnerability) can retrieve both the ciphertext and the key in the same breach. With both in hand, decrypting the entire database is trivial, so the encryption provides no real defence against a server compromise, only against someone who copies the database file without also gaining server access.
A more secure design keeps the key in a separate key management service (KMS) or hardware security module (HSM), so that compromising the database server alone does not automatically expose the key.
Marking criteria: 1 mark for identifying that a single breach can expose both ciphertext and key, 1 mark for explaining this defeats the purpose of encryption, 1 mark for stating what protection remains (against database-only theft), 1 mark for recommending a separated key store (KMS/HSM).
core5 marksA mobile banking app uses RSA to encrypt a freshly generated AES session key at the start of each login session, then uses AES for all messages sent during that session. Explain the security purpose of this hybrid design, and identify what would happen to security if the same AES session key were reused across many days instead of being generated fresh each session.Show worked solution →
Purpose of the hybrid design. RSA solves the key-exchange problem: the app and the bank's server have never shared a secret in advance, so RSA lets the app securely send a brand-new AES key to the server (only the server's private key can decrypt it). Once both sides hold the same AES key, all further traffic is encrypted with fast symmetric AES, giving practical performance for a session that may carry large amounts of data.
Effect of reusing the same session key across many days. If the AES key were reused rather than regenerated per session, a single compromise of that key (for example through malware capturing it in device memory) would expose every session's traffic across the entire reuse period, not just one login. It also gives an attacker far more ciphertext encrypted under the same key to analyse, increasing the practical risk of cryptanalysis. Generating a fresh session key each time limits the "blast radius" of any single key compromise to one session only.
Marking criteria: 1 mark for explaining RSA's role in key exchange, 1 mark for explaining AES's role in bulk session traffic, 1 mark for identifying increased exposure window if the key is reused, 1 mark for identifying more ciphertext available to an attacker as a risk, 1 mark for explicitly contrasting this with the "blast radius" limited to one session under the fresh-key design.
exam6 marksAssess the claim: 'Asymmetric encryption is fundamentally more secure than symmetric encryption because it uses two keys instead of one.' Refer in your answer to the role both types of encryption play in a system like HTTPS.Show worked solution →
This is a 6-mark ASSESS: markers reward a supported judgement, not just a description of each type.
Plan.
- Thesis: the claim is false. Security strength depends on algorithm design and key length, not on the number of keys involved; both symmetric and asymmetric encryption are considered strong when properly implemented at recommended key sizes (AES-256, RSA-2048/4096).
- Evidence against the claim: AES-256 and RSA-2048 are both currently considered computationally infeasible to break by brute force with existing technology; NESA-level treatments describe them as comparably secure at these key sizes, not one strictly "more secure" than the other.
- What actually differs: the two-key structure of asymmetric encryption solves a different PROBLEM (key exchange without a prior shared secret and enabling digital signatures), not a higher SECURITY LEVEL. Symmetric encryption's single-key structure is a key-management liability, not a security weakness in the cipher itself.
- HTTPS as evidence: HTTPS deliberately uses only a small amount of asymmetric encryption (the handshake) and relies overwhelmingly on symmetric encryption (AES) for the actual data. If asymmetric encryption were unconditionally "more secure", HTTPS would use it throughout; instead, real systems choose the right tool for the job, using each type where its specific properties (fast bulk encryption versus solving key exchange) are needed.
- Judgement: the number of keys is a design choice serving key management and signing needs, not a security tier; a well-implemented hybrid system is more secure overall than either type used alone, which contradicts the premise that more keys automatically means more security.
Marker's note: top-band answers (1) explicitly reject the premise with a reason (security depends on algorithm/key length, not key count), (2) use HTTPS as concrete supporting evidence of both types being used for different purposes, (3) explain what the two-key structure actually buys (key exchange, signatures) rather than restating that it "sounds" more secure, and (4) close with an explicit judgement.
exam6 marksA start-up encrypts all stored customer credit card numbers using AES-256, with a single encryption key hard-coded in the application's source code, and that source code repository is set to public on GitHub. Evaluate the effectiveness of this encryption scheme and recommend two specific improvements.Show worked solution →
Evaluation. The choice of algorithm (AES-256) is not the problem: AES-256 is a strong, industry-standard symmetric cipher, and the encryption itself is technically sound. The scheme fails entirely at key management. Because the key is hard-coded in source code that sits in a public repository, anyone in the world can read the key without ever attacking the database or the server. This makes the encryption effectively worthless: an attacker does not need to break AES at all, they simply copy the key from GitHub and decrypt any stolen ciphertext directly. This mirrors the general principle that encryption is only as strong as the protection around its key, and a single global key also means one leak exposes every customer's card number at once, rather than limiting the damage to one record or one time period.
Recommended improvements (two required):
- Move the key out of source code entirely into a dedicated key management service or hardware security module (HSM), and make the source repository private, so the key is never committed to version control.
- Use envelope encryption with per-record or periodically rotated data-encryption keys (each protected by a master key in the KMS), so that a single leaked key does not expose the entire customer base, and rotate keys on a schedule.
Other acceptable improvements: restrict repository access with proper permissions and secret-scanning tools, or move to a managed database-level encryption feature that never exposes the raw key to the application layer.
Marking criteria: 1 mark for correctly noting AES-256 itself is not the weakness, 1 mark for identifying the public hard-coded key as a critical failure, 1 mark for explaining that this bypasses the need to break the cipher at all, 1 mark for explaining the single-key/large blast-radius risk, 2 marks for two specific, workable improvements (KMS/HSM, envelope encryption/key rotation, private repo/secret scanning).