All questions
Question 1
A company has 15 branch offices. Security policy requires every pair of offices to communicate using a secret that no other branch knows. The company is comparing pairwise symmetric keys with an asymmetric design in which each branch maintains one public/private key pair.
Which statement most accurately compares the key-management implications of the two designs?
- The symmetric design needs 15 shared keys, while the asymmetric design needs 105 private keys.
- The symmetric design needs 105 shared keys, while the asymmetric design needs 15 private keys. (correct answer)
- Both designs need 105 secret keys because every communicating pair requires two protected values.
- Both designs need 15 secret keys because each branch can reuse one secret with all other branches.
Explanation: When comparing symmetric and asymmetric key designs, the core question is always: what must be kept secret, and how many of those secrets exist?
In a symmetric design, every pair of branches shares a unique secret key that no third branch can know. With 15 branches, the number of unique pairs is calculated using the combination formula: (215)=215×14=105 So the symmetric design requires 105 shared secret keys — one per pair. In the asymmetric design, each branch generates its own public/private key pair. The public key is freely distributed (no secrecy needed), so only the private key must be protected. With 15 branches, that's just 15 private keys — one per branch. This makes B the correct answer.
Choice A reverses the math entirely — 15 shared keys would only work if branches reused a single secret with everyone, violating the "no other branch knows" requirement. The 105 figure is correct for symmetric but incorrectly attributed to private keys in asymmetric. Choice C incorrectly claims both designs require 105 secret values. In asymmetric cryptography, public keys are not secret — the whole point is they're published openly. Counting them as protected values betrays a fundamental misunderstanding. Choice D claims both designs need only 15 keys, which confuses the asymmetric case (correct at 15) with the symmetric case (wrong — reusing one key across all partners would mean every branch could decrypt every other branch's messages).
A useful memory anchor: symmetric = shared secrets scale combinatorially, asymmetric = each party protects only their own private key. This tradeoff — 105 vs. 15 — is exactly why asymmetric designs win on scalability. Question 2
A software vendor must send a 4 GB confidential update to thousands of customers. Each customer already has an authenticated copy of the vendor's public key, but the vendor does not share a separate symmetric key with every customer.
Which design most appropriately uses the strengths of symmetric and asymmetric encryption?
- Encrypt the entire update with the vendor's private key, then let customers decrypt with the public key.
- Encrypt the entire update separately with each customer's public key and avoid symmetric encryption.
- Encrypt the update with a symmetric session key and publish that session key in the download metadata.
- Encrypt the update symmetrically and protect the session key for each customer using asymmetric encryption. (correct answer)
Explanation: When a question asks about combining symmetric and asymmetric encryption, think about what each does best: symmetric encryption is fast and efficient for large data, while asymmetric encryption excels at secure key exchange without requiring a pre-shared secret. The challenge is always: how do you get the symmetric key to the recipient safely?
This is exactly the hybrid encryption model, and D describes it perfectly. The vendor encrypts the 4 GB update once using a symmetric session key — fast and practical at scale. Then, for each customer, that session key is encrypted with the customer's public key (asymmetric encryption). Only the customer's private key can unlock the session key, which then unlocks the update. This gives you efficiency and confidentiality, with no pre-shared secrets required.
A is a common misconception trap. Encrypting with a private key isn't confidentiality — it's the basis of digital signatures. Anyone with the vendor's public key (which is everyone) can decrypt it, so nothing is actually protected.
B is computationally disastrous. Encrypting a 4 GB file separately with asymmetric encryption for thousands of customers would be extraordinarily slow — asymmetric algorithms aren't designed for bulk data encryption. This ignores the entire reason symmetric encryption exists.
C gets halfway there but then ruins it. Publishing the session key openly in the metadata means anyone can decrypt the update — there's no protection at all. Key confidentiality is the whole point.
A useful mental anchor: in real-world protocols like TLS, the pattern is always "encrypt data symmetrically, protect the key asymmetrically." Recognizing that hybrid model is the exam signal for the right answer.
Question 3
A team must establish confidential communication between two newly deployed devices. The devices currently have no shared secret, but each has an authenticated copy of the other's public key. The network is monitored by an attacker.
Which approach avoids sending a reusable symmetric secret in plaintext while still allowing efficient ongoing communication?
- One device sends a new symmetric session key encrypted with the other device's public key, so only the recipient's private key can recover it for subsequent use. (correct answer)
- One device sends its private key encrypted with the other device's public key, allowing the recipient to use it for decryption and future message signing.
- Both devices transmit identical plaintext passwords over the monitored network and then derive symmetric session keys from those passwords.
- Both devices exchange public keys a second time and concatenate those public values to form a single symmetric key for all subsequent traffic.
Explanation: When you see a question about establishing secure communication between devices that already have each other's public keys, you're being tested on the fundamentals of hybrid cryptography — combining asymmetric encryption's key-exchange strength with symmetric encryption's efficiency for bulk data.
The goal is to share a symmetric session key without ever exposing it on the network. Answer A accomplishes exactly this: one device generates a fresh symmetric key, encrypts it using the recipient's public key, and sends the ciphertext. Only the recipient's corresponding private key can decrypt it, so the symmetric secret is never exposed in transit. Once both parties have that session key, they switch to fast symmetric encryption for all ongoing traffic — this is the standard hybrid model used in TLS and similar protocols.
Answer B is a serious security violation. Private keys must never leave the device that owns them. Sending a private key — even encrypted — destroys the entire trust model, because the recipient could impersonate the sender or forge signatures. This is never a legitimate protocol step.
Answer C exposes the secret directly. Transmitting identical plaintext passwords over a monitored network means the attacker sees exactly what you're deriving your keys from, rendering the derived session key trivially compromised.
Answer D is subtly wrong because concatenating two public keys doesn't create a secret — public keys are, by definition, public. Any network observer can perform the same concatenation and "derive" the same value, so nothing is actually protected.
A useful mental check: ask yourself whether an attacker watching the wire could reconstruct the key. If yes, the approach fails. Answer A is the only option where they cannot.
Question 4
Alice and Bob use a single symmetric key for confidential messages. Carol later obtains that key. In a separate system, Carol obtains only Bob's public key, whose authenticity has been verified.
Which statement correctly compares Carol's capabilities in the two systems?
- The symmetric key lets Carol decrypt and create messages; Bob's public key lets her encrypt messages to Bob. (correct answer)
- The symmetric key lets Carol encrypt but not decrypt; Bob's public key lets her decrypt Bob's messages.
- Both keys let Carol decrypt prior messages because encryption keys always reverse their own operations.
- Neither key lets Carol create ciphertext because message encryption always requires a private secret.
Explanation: Whenever you see a question mixing symmetric and asymmetric cryptography, anchor yourself to one core question: who holds which key, and what does each key actually do?
In a symmetric system, a single shared key both encrypts and decrypts. If Carol obtains that key, she can do everything the legitimate parties can — decrypt stored or intercepted messages and forge new ciphertext that appears authentic. The key grants full bidirectional power. In an asymmetric (public-key) system, the public key encrypts while the private key decrypts. Bob's public key is freely shareable by design. If Carol has it, she can encrypt messages to Bob — but she cannot decrypt anything, because only Bob's private key does that. This makes A the correct answer: the symmetric key grants Carol both decrypt and encrypt capabilities, while Bob's public key grants her only the ability to encrypt messages addressed to Bob.
B is backwards — it reverses the roles of the symmetric key, claiming it encrypts but not decrypts, which contradicts how symmetric cryptography works. C introduces a false principle: encryption keys do not automatically "reverse their own operations." Public keys encrypt; they do not decrypt. D is also wrong — encryption absolutely does not require a private secret. Public keys exist precisely so anyone can encrypt without possessing secret material.
Study tip: Memorize this asymmetric rule: public key locks (encrypts), private key unlocks (decrypts). Exam questions frequently swap these roles as distractors, so drilling this pairing will help you spot reversals instantly.
Question 5
Two administrators use the same symmetric key to generate authentication tags for change requests. After a disputed request is accepted, each administrator claims the other created it. The tag is valid.
Why does the valid tag fail to establish which administrator created the request?
- Either administrator possessed the same secret and could have produced the valid tag. (correct answer)
- Symmetric authentication protects confidentiality but cannot detect modification of a request.
- Only asymmetric encryption can validate data after it has traveled over an untrusted network.
- The tag proves which administrator sent it, but the verifier discarded the sender's public key.
Explanation: When you see a question about message authentication codes (MACs) or authentication tags, immediately ask yourself: who holds the key, and what does possession of that key imply?
Symmetric authentication works by having both parties share one secret key. Either party uses that same key to generate a valid tag, and either party can verify it. This is the core limitation — because both administrators held identical keys, both were equally capable of producing the disputed tag. A valid tag only proves that someone with the key created the request; it cannot distinguish which keyholder did so. This is why A is correct and captures the fundamental property at stake: non-repudiation is impossible when the secret is shared.
B is wrong because the issue here isn't confidentiality or tamper detection — MACs actually do detect modification effectively. The problem is attribution, not integrity. C is wrong on two counts: asymmetric encryption doesn't automatically solve authentication, and the claim that symmetric schemes fail specifically "over untrusted networks" misidentifies the real problem. D is the sneakiest distractor — it sounds technical, but it invents a scenario where a public key was discarded. Symmetric authentication doesn't use public keys at all, so this answer mixes up asymmetric and symmetric concepts entirely.
The study tip here is to always connect non-repudiation with asymmetric (public-key) systems. Asymmetric schemes give each party a unique private key, so a valid signature can only come from one person. Whenever a question involves proving who specifically did something, the answer almost always points to the absence of asymmetric cryptography — or, as here, the presence of a shared symmetric key.
Question 6
An application uses one shared secret for all members of a project team. The secret encrypts documents and also authenticates messages. One member leaves the project, and the organization wants that person unable to read future documents or create future valid messages.
Which action is necessary under this symmetric design?
- Remove the former member's username because possession of the old shared key no longer grants access.
- Keep the shared key for encryption but change only the former member's message-authentication password.
- Publish the shared key as a public key and retain a private copy for the remaining team members.
- Replace the shared key and securely distribute the replacement to all remaining authorized members. (correct answer)
Explanation: When a single shared secret serves double duty — both encrypting data and authenticating messages — every team member's access depends entirely on possession of that one key. This is the core vulnerability of symmetric key designs: the key is the credential. So when someone who holds that key leaves, you cannot simply revoke their "account" — you must invalidate the key itself.
That's why D is correct. Because the departing member still possesses the old shared key, any document encrypted with it remains readable to them, and any message authenticated with it could be forged by them. The only solution is to generate a brand-new key, distribute it securely to all remaining authorized members, and use it going forward. The former member, lacking the new key, is effectively locked out of both capabilities.
A is wrong because usernames and access accounts are irrelevant here — cryptographic access comes from key possession, not identity management. The former member doesn't need a username; they need the key, which they already have.
B is wrong because it assumes encryption and authentication are governed by separate credentials. In this symmetric design, one shared secret handles both. You cannot split them — changing only a "message-authentication password" leaves the encryption key (and thus document confidentiality) fully compromised.
C is wrong and introduces a dangerous confusion between symmetric and asymmetric cryptography. Publishing a shared secret as a "public key" destroys its secrecy entirely and is not how either cryptographic model works.
Study tip: On any exam question involving shared secrets and personnel changes, ask yourself: who still holds the key? If the answer is "someone unauthorized," the key must be replaced — no workaround exists.
Question 7
Remote sensors must upload confidential reports to a server. Each sensor is provisioned only with an authenticated copy of the server's public key. The server possesses the corresponding private key, and no sensor has a shared secret with the server.
Which conclusion about the report-encryption mechanism is best supported by this design?
- It is symmetric because every sensor uses the same public value when encrypting reports.
- It is asymmetric because encryption and decryption depend on different, mathematically related keys. (correct answer)
- It is symmetric because only the server can decrypt, making the private key a shared secret.
- It is asymmetric only if every sensor receives a different copy of the server's public key.
Explanation: Whenever you see a question about encryption design, ask yourself one foundational question: does the same key both encrypt and decrypt, or do two different keys handle those roles? That distinction separates symmetric from asymmetric (public-key) cryptography.
In this scenario, sensors encrypt reports using the server's public key, and the server decrypts them using its private key. These are two mathematically related but distinct keys — you cannot derive one from the other in any practical sense. This is the defining characteristic of asymmetric cryptography, which makes B correct: encryption and decryption depend on different, mathematically linked keys. The sensors never need a shared secret; they only need the public key, which can be freely distributed.
A contains a seductive but flawed logic — yes, every sensor uses the same public key, but "same value used to encrypt" does not make something symmetric. In symmetric cryptography, that same value must also decrypt. Here, it cannot. The shared public key is a feature of asymmetric design, not evidence against it.
C confuses "only one party can decrypt" with "shared secret." A shared secret means both parties possess the same secret value. The private key is never shared with the sensors — it stays exclusively on the server. That's the whole point.
D is a fabricated condition. Asymmetric cryptography does not require each party to have a unique copy of the public key. A single published public key works for all senders.
Study tip: Memorize this anchor — asymmetric = two keys (public encrypts, private decrypts); symmetric = one shared secret key does both. Exam distractors will blur this line every time.
Question 8
An employee applies an operation to a document using the employee's private key. Anyone with the employee's authenticated public key can validate the resulting value. A manager claims this operation keeps the document confidential because a private key was used.
What is the best assessment of the manager's claim?
- The claim is correct because any operation using a private key necessarily provides confidentiality.
- The claim is correct if the public key is distributed only to intended document recipients.
- The claim is incorrect because this describes signature verification, not confidential encryption. (correct answer)
- The claim is incorrect because private keys can support integrity only when shared with verifiers.
Explanation: When you see a question involving private keys and validation by others, immediately ask yourself: which cryptographic operation is this describing — encryption or digital signatures? These two operations use keys in opposite directions and serve completely different security goals.
Here, the employee applies an operation with their private key, and anyone with the corresponding public key can verify the result. This is the textbook definition of a digital signature. In asymmetric cryptography, signing means hashing the document and encrypting that hash with your private key. Verifiers use your public key to decrypt and confirm the hash matches — proving authenticity and integrity, not confidentiality. The document itself remains readable by anyone. Answer C correctly identifies this: the manager has confused signing with confidential encryption.
A is wrong because operations using a private key do not automatically provide confidentiality. Signing with a private key makes verification public — the opposite of restricting access. Confidentiality requires encrypting with the recipient's public key, not the sender's private key.
B is a tempting trap. Even if you distribute the public key only to certain people, it doesn't make the document confidential — those people are verifying authenticity, not decrypting secret content. The document was never encrypted to begin with.
D contains a subtle misconception. Private keys don't need to be "shared" with anyone to support integrity — that's the whole point of asymmetric systems. The private key stays secret; the public key is what verifiers use.
Study tip: Memorize the direction of key usage — encrypt for confidentiality using the recipient's public key; sign for integrity using your own private key. Mixing these up is one of the most common traps on security exams.
Question 9
A disaster-recovery service wants employees to upload encrypted backups from laptops that may later be stolen. Laptops should be able to create new backups but should not contain any key capable of decrypting existing backups. Recovery occurs only on an isolated server.
Which key arrangement best meets these requirements?
- Place one symmetric backup key on every laptop and keep an additional copy on the recovery server.
- Place the recovery server's public key on every laptop and retain its private key only on the server. (correct answer)
- Place the recovery server's private key on every laptop and publish its public key for recovery.
- Generate a different symmetric key on each laptop and store that key beside every encrypted backup.
Explanation: When a question describes a system where encryption must happen on an untrusted device but decryption must never happen there, you should immediately think of asymmetric (public-key) cryptography. The core insight is that a public key can only encrypt — possessing it gives an attacker no ability to recover plaintext.
In this scenario, each laptop needs to encrypt backups but must never be able to decrypt them, since the laptop could be stolen. The ideal solution is to place the recovery server's public key on every laptop. The laptop encrypts backups with that public key, but only the server — holding the matching private key — can ever decrypt them. This is exactly what B describes, and it perfectly satisfies all three requirements: laptops encrypt freely, stolen laptops yield nothing useful, and recovery remains exclusive to the server.
A is wrong because a symmetric key both encrypts and decrypts. Any attacker who steals the laptop also steals the ability to read all existing backups — a critical failure of the stated requirement.
C reverses the asymmetric model catastrophically. Placing the private key on laptops means a thief can decrypt every backup ever made by any laptop. Publishing the public key doesn't help — you'd be handing attackers the decryption capability directly.
D stores the symmetric key alongside the encrypted data, which is equivalent to leaving the house key under the doormat. Encryption provides no protection if the key travels with the ciphertext.
A good study tip: when you see "encrypt here, decrypt only there," map it to public-key infrastructure — the encrypting side always gets the public key, never the private one.
Question 10
An engineer classifies an encryption system as symmetric because the sender and recipient run the same software and use the same algorithm. However, the sender encrypts with a published key, and the recipient decrypts with a separately protected key that is mathematically related to the published key.
Which fact is decisive when classifying the system?
- Using identical software makes the system symmetric even when the configured keys are different.
- Using the same algorithm makes the system symmetric because encryption and decryption are paired operations.
- Using distinct related keys makes the system asymmetric despite identical software and algorithm implementations. (correct answer)
- Publishing either key makes the system symmetric because all senders begin with one common value.
Explanation: Whenever a question asks you to classify an encryption system as symmetric or asymmetric, ignore the implementation details like software or algorithm choice — focus entirely on the key relationship. The defining criterion is simple: symmetric systems use the same key to encrypt and decrypt, while asymmetric systems use two mathematically related but distinct keys (a public key and a private key).
In this scenario, the sender encrypts with a published (public) key and the recipient decrypts with a separately protected (private) key. Those are two different keys, which is the textbook definition of asymmetric (public-key) cryptography. That makes C correct: distinct related keys define the system as asymmetric, regardless of what the software or algorithm looks like under the hood.
A is wrong because the software implementation is irrelevant to classification. RSA and AES can both be coded in Python — that doesn't make them the same type of system. Shared software is a red herring. B makes a similar mistake with algorithm identity. Many asymmetric systems use the same underlying algorithm for both operations (e.g., RSA for both encryption and decryption), but that doesn't make them symmetric — the key distinction is literally the key. D confuses "published" with "shared." Publishing a public key doesn't mean all parties use that single key for both directions; it means anyone can encrypt, but only the private-key holder can decrypt. That is the opposite of symmetric behavior.
Your study tip: when classifying cryptographic systems, train yourself to ask one question first — same key or different keys? Everything else is secondary.