Cyber Security Quiz: Encryption Hashing And Encoding
10 questions · exam conditions
0:00
Encryption Hashing And EncodingQuestion 1 of 10

After a password database breach, an administrator reports that passwords were stored as unique salted cryptographic hashes. A manager asks whether the incident-response team can decrypt the hashes to determine which passwords were exposed.

Which response is most accurate?

The team can decrypt each hash after retrieving the corresponding salt, because the salt functions as a decryption key.
The team can decode each hash using its documented output format, although salting will alter the recovered password.
The hashes are not decrypted; investigators can only test password guesses by hashing each guess with the relevant salt.
The hashes are mathematically unrecoverable, so even testing likely password guesses against them is not possible.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Encryption Hashing And Encoding

Practice Encryption Hashing And Encoding in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Encryption Hashing And Encoding, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

After a password database breach, an administrator reports that passwords were stored as unique salted cryptographic hashes. A manager asks whether the incident-response team can decrypt the hashes to determine which passwords were exposed.

Which response is most accurate?

  1. The team can decrypt each hash after retrieving the corresponding salt, because the salt functions as a decryption key.
  2. The team can decode each hash using its documented output format, although salting will alter the recovered password.
  3. The hashes are not decrypted; investigators can only test password guesses by hashing each guess with the relevant salt. (correct answer)
  4. The hashes are mathematically unrecoverable, so even testing likely password guesses against them is not possible.
Explanation: When you see a question about password storage and breaches, anchor yourself to one foundational concept: cryptographic hashing is a one-way function. Unlike encryption, hashing has no reverse operation — there is no key, no algorithm, and no mathematical pathway that transforms a hash back into its original input. This is precisely why C is correct. Investigators cannot "decrypt" hashes because decryption implies a reversible process that simply doesn't exist here. What they can do is perform hash-matching: take a candidate password, apply the same hashing algorithm combined with the stored salt, and compare the output to the stored hash. If they match, the password is confirmed. The salt doesn't unlock anything — it's simply mixed into the input before hashing, ensuring that identical passwords produce different hashes across users, which defeats precomputed rainbow-table attacks. A contains a classic misconception — it treats the salt as a decryption key. Salts are not secret keys; they're typically stored alongside the hash. They prevent precomputation attacks but have no role in any decryption process, because no such process exists. B is wrong on two levels. "Decoding" implies a reversible encoding scheme (like Base64), not hashing. Additionally, the statement that salting "alters the recovered password" is nonsensical — you cannot recover the password at all. D goes too far in the right direction. While hashes are non-reversible, testing guesses is entirely possible through the hash-matching process described above — this is exactly how attackers crack weak passwords post-breach. Your study tip: memorize the distinction between encryption (reversible, uses keys), encoding (reversible, no keys), and hashing (irreversible, one-way). Exam questions frequently blur these terms to test whether you know the difference.

Question 2

A software publisher posts an installer and its SHA-256 value on the same website. An administrator downloads both and confirms that the installer produces the posted value. An attacker, however, had gained control of the website and replaced both the installer and the posted SHA-256 value.

What does the administrator's successful comparison establish in this situation?

  1. It proves the installer is authentic because matching hashes cannot be supplied for attacker-controlled files.
  2. It proves the installer is confidential because SHA-256 prevents observers from recovering the file contents.
  3. It shows consistency with the posted digest, but not authenticity because the attacker controlled both values. (correct answer)
  4. It shows the installer was encoded correctly, but only decoding the SHA-256 value can establish authenticity.
Explanation: Whenever you see a question about file integrity verification, ask yourself: what trust assumptions are baked into the verification method? A hash like SHA-256 only tells you that two things match — it says nothing about whether either thing is trustworthy. Here's the core issue: SHA-256 is a deterministic algorithm anyone can run. If an attacker replaces both the installer and the posted hash, they simply compute SHA-256(malicious_installer) and post that new value. The administrator runs the same computation and gets a match — but a match against an attacker-generated digest. The comparison confirms internal consistency, not authenticity. That's exactly what C captures: the hash matched the posted digest, but since the attacker controlled both, the comparison carries no authenticity guarantee. A is wrong because it assumes attackers cannot produce matching hashes for their own files — they absolutely can. SHA-256 is publicly available; generating a valid hash for any file is trivial. The difficulty lies in collisions (two different files producing the same hash), not in hashing arbitrary content. B is wrong because SHA-256 is a one-way hash function, not an encryption scheme — it provides integrity checking, not confidentiality. You cannot "recover file contents" from a hash, but that's irrelevant to what the question is asking. D is wrong on two counts: SHA-256 values aren't "encoded" files awaiting decoding, and no decoding step exists. SHA-256 produces a fixed-size digest, not a reversible encoding. The study tip: hash-based integrity only works when the hash is delivered through a separate, trusted channel (like a signed release or a different server). Same-source hashes are vulnerable to this exact substitution attack.

Question 3

A privacy team needs to replace employee identifiers in analytics records. Analysts must be able to group records belonging to the same employee, but they must not be able to directly reverse a stored replacement value. The identifiers come from a small, predictable range.

Which statement best evaluates replacing each identifier with an unsalted cryptographic hash?

  1. It supports consistent grouping, but predictable identifiers may still be discovered by hashing every likely candidate. (correct answer)
  2. It prevents both direct reversal and guessing because cryptographic hashes produce fixed-length outputs for all inputs.
  3. It supports consistent grouping only if analysts possess the secret decryption key used by the hashing algorithm.
  4. It prevents candidate testing, but identical identifiers will produce unrelated hash values during separate processing runs.
Explanation: When evaluating a pseudonymization technique, you need to ask two questions: does it support consistent grouping, and does it truly prevent reversal? The answer hinges on a critical property of cryptographic hashes — they are deterministic but not secret. Because a hash function always produces the same output for the same input, replacing employee IDs with their hashes lets analysts group records correctly: two rows with the same employee will share the same hash. However, when identifiers come from a small, predictable range — think employee numbers 1–10,000 — an attacker can simply hash every candidate value and compare results against the stored hashes. This is called a brute-force enumeration or dictionary attack, and it works precisely because the range is exhaustible. That reasoning confirms A as correct: consistent grouping is preserved, but the predictable input space makes the hashes reversible in practice. B is wrong because it confuses a property of hash outputs (fixed length) with a security guarantee. Fixed-length output does not prevent someone from hashing all plausible inputs and matching them — it says nothing about resistance to enumeration attacks. C is wrong because hash functions are not encryption and involve no decryption key. This answer conflates hashing with symmetric encryption, which is a fundamental misconception about how these primitives work. D is wrong because it reverses reality. Cryptographic hash functions are deterministic — the same input always yields the same output, whether processed today or next year. Identical identifiers will always produce identical hashes, not unrelated ones. Study tip: Whenever a question mentions a "small, predictable range," that's a signal that unsalted hashing is vulnerable to enumeration — a salt randomizes the input space and closes this gap.

Question 4

A web application replaces spaces in a search phrase with %20 before placing the phrase in a URL. A developer argues that this protects confidential search terms because the browser no longer displays the exact original characters.

Which analysis most accurately addresses the developer's claim?

  1. The replacement is hashing because the altered phrase has a different length and therefore cannot be reconstructed reliably.
  2. The replacement is encryption because the browser must apply a protocol-specific key to restore each space.
  3. The replacement is encoding for transport syntax and can be reversed without a secret, so it provides no confidentiality. (correct answer)
  4. The replacement is encryption only when HTTPS is used, because HTTPS converts URL encoding into ciphertext automatically.
Explanation: When a question asks whether a transformation provides confidentiality, your first instinct should be to classify the transformation: is it encoding, encryption, or hashing? Each has a fundamentally different relationship with secrecy. URL percent-encoding (replacing a space with %20, < with %3C, etc.) is a reversible, public syntax rule defined in RFC 3986. Any browser, tool, or person who knows the standard — which is everyone — can instantly reconstruct the original string. No key, no password, no secret of any kind is required. That's why C is correct: the replacement is encoding for transport syntax, and because it's trivially reversible without a secret, it offers zero confidentiality. The developer's claim is false. A is wrong on two counts: encoding doesn't change length in an unpredictable way (a space always becomes exactly %20), and hashing is a one-way function — you can't reliably reconstruct the original. Calling this hashing misidentifies both the mechanism and the property. B is wrong because encryption requires a secret key and a cryptographic algorithm. No key is involved in percent-encoding; the "protocol" doesn't decrypt anything — it simply reads a publicly documented substitution table. D is a common trap. HTTPS does encrypt URL content in transit, but that's a separate layer. Percent-encoding itself is not converted into ciphertext by HTTPS — it remains plain encoding inside the encrypted channel. Mixing these two concepts is a classic misconception. Study tip: On security exams, always ask: "Does reversing this transformation require a secret?" If the answer is no, it's encoding — not encryption — and it provides no confidentiality on its own.

Question 5

An organization archives confidential reports. Authorized employees must later recover each report exactly, and the archive process must also permit detection of accidental file corruption. The storage platform does not provide either capability automatically.

Which processing approach most directly satisfies both requirements?

  1. Encrypt each report for confidentiality and retain a cryptographic hash of each plaintext report for later corruption detection. (correct answer)
  2. Hash each report to protect its contents from disclosure and retain its Base64 representation to reconstruct the report later.
  3. Base64-encode each report to conceal its contents and encrypt the report's hash so it can be used to rebuild a corrupted file.
  4. Hash each report to preserve a recoverable copy of its contents and encrypt the resulting digest to protect the stored record.
Explanation: When a question lists two distinct requirements — here, confidentiality and integrity verification — your job is to match each requirement to the correct cryptographic tool. Encryption provides confidentiality by transforming plaintext into unreadable ciphertext that only authorized parties can reverse. Cryptographic hashing produces a fixed-length digest that acts as a fingerprint: if even one byte of the file changes, the hash changes, enabling corruption detection. These are separate tools solving separate problems. Answer A is correct because it applies each tool to the right job. Encrypting the report satisfies confidentiality — authorized employees decrypt it to recover the exact original. Retaining a hash of the plaintext report enables corruption detection: after decryption, you rehash and compare against the stored digest. Both requirements are fully and correctly addressed. Answer B fails on two counts: hashing does not conceal content (hashes are one-way and non-reversible), and Base64 is encoding, not encryption — it provides zero confidentiality. You cannot "reconstruct the report" from a hash. Answer C confuses roles again. Base64 encoding is trivially reversible by anyone and offers no real concealment. Encrypting a hash doesn't help rebuild a corrupted file — a hash is not a backup copy of the data. Answer D makes the classic reversal error: it claims hashing "preserves a recoverable copy," which is false. Hashes are one-way digests, not compressed or stored versions of the original file. Encrypting the digest adds nothing useful here. A useful study habit: memorize the one-way vs. reversible distinction. Encryption is reversible (with a key); hashing is not. Any answer that assigns recovery to a hash is automatically wrong.

Question 6

A records system must conceal the contents of customer documents while allowing an authorized duplicate-detection service to identify documents that are byte-for-byte identical. The design encrypts each document with randomized encryption and separately stores an unkeyed cryptographic hash of its plaintext.

Which assessment of this design is most accurate?

  1. Randomized encryption enables duplicate detection because identical plaintexts always produce identical ciphertexts.
  2. The plaintext hashes can reveal duplicate groups, although they also expose equality information about the documents. (correct answer)
  3. The plaintext hashes permit authorized recovery of documents if the randomized encryption key is later lost.
  4. Encoding each ciphertext would provide the same duplicate detection while avoiding equality information leakage.
Explanation: When a system needs to both protect confidentiality and detect duplicates, you're navigating a fundamental tension in cryptographic design. Ask yourself: what does each component reveal, and to whom? The core insight here is that hashing and encryption serve different purposes. Randomized encryption (like AES-GCM with a random nonce) deliberately produces different ciphertexts from identical plaintexts — that's the whole point. But a deterministic, unkeyed hash always maps the same input to the same digest. So two identical documents will produce identical hashes, letting the duplicate-detection service compare hashes instead of plaintexts. That makes B correct: the hashes successfully enable duplicate detection. However, "unkeyed" means anyone with access to the hash store can check whether any plaintext they suspect maps to a stored hash — confirming or denying equality without ever decrypting anything. This is called equality leakage, and it's a real privacy risk. A is backwards. Randomized encryption is specifically designed so identical plaintexts don't produce identical ciphertexts, making it useless for duplicate detection on its own. C confuses hashing with encryption. A hash is a one-way function — you cannot reverse it to recover the original document. It offers no recovery capability whatsoever. D is a red herring. Encoding (e.g., Base64) is not encryption or hashing — it's just a representation change. Encoding ciphertexts reveals nothing new and does nothing to support duplicate detection or reduce equality leakage. Study tip: On security design questions, always trace what information each component leaks — correct designs minimize leakage; distractors often conflate different cryptographic primitives (hashing vs. encryption vs. encoding).

Question 7

A document-approval system calculates a cryptographic hash of a large contract and applies a digital-signature operation to that hash. The signed hash and the contract are then Base64-encoded for transport through a text-only messaging system.

Which interpretation of the processing steps is most accurate?

  1. Base64 performs the digital-signature operation over the transmitted data, while hashing converts the resulting signature into a format that text-only channels can carry.
  2. Hashing encrypts the contract contents to provide confidentiality during storage, while Base64 encodes the recipient's authentication credentials for the verification step.
  3. Base64 conceals the contract from unauthorized observers during transit, while hashing allows the recipient to reconstruct any sections of the contract that were lost or corrupted.
  4. Hashing compresses the contract into a fixed-size digest for efficient signing, while Base64 only converts the binary output into text-safe characters for transport. (correct answer)
Explanation: When you see a question combining hashing, digital signatures, and encoding, slow down and ask yourself: what is each operation actually doing? These three technologies serve completely different purposes, and exam questions love to swap their roles. Hashing takes an arbitrarily large input — like a multi-page contract — and produces a fixed-length digest (e.g., 256 bits for SHA-256). This digest is what gets digitally signed, not the entire document. Signing a small digest is computationally efficient and mathematically equivalent to signing the original, since any change to the contract produces a completely different digest. Base64, by contrast, does nothing cryptographic — it simply re-encodes binary data (the contract bytes, the signature bytes) into a printable ASCII character set so that text-only systems (email, certain APIs) can carry it without corruption. D captures both roles precisely: hashing compresses to a fixed-size digest for efficient signing, and Base64 converts binary output into transport-safe text. A reverses the roles entirely — Base64 cannot perform digital signatures, and hashing has nothing to do with text encoding. This is a straightforward role-swap trap. B introduces confidentiality and authentication credentials, neither of which applies here; hashing is not encryption and provides no confidentiality, and Base64 is not an authentication mechanism. C wrongly claims Base64 conceals data (it offers zero confidentiality — anyone can decode it instantly) and that hashing enables reconstruction of lost data (a hash is one-way and lossy by design; you cannot recover the original from it). Your study tip: memorize the one-liner for each — hash = fingerprint, signature = proof of origin, Base64 = text wrapper. If an answer assigns one technology's job to another, eliminate it immediately.

Question 8

A security engineer proposes three transformations for audit records: encrypt them before storage, calculate a cryptographic hash for change detection, and encode stored binary values as hexadecimal text. A reviewer asks what a successful reversal of each transformation would require.

Which statement correctly distinguishes the three transformations?

  1. Encryption normally requires an authorized key to reverse, encoding requires the defined decoding rules, and hashing has no general reversal operation. (correct answer)
  2. Encryption and hashing both require secret keys to reverse, while encoding can be reversed only by recomputing its checksum.
  3. Encryption has no general reversal operation, hashing requires the original key, and encoding requires a matching initialization vector.
  4. Encryption requires only the public algorithm, hashing requires a decoding alphabet, and encoding requires the original secret key.
Explanation: When you encounter a question about cryptographic operations, the key is understanding each transformation's reversibility: who can reverse it, and under what conditions? Encryption is a two-way transformation — it's designed to be reversed, but only by someone possessing the correct key. Without the key, reversal is computationally infeasible. Encoding (like binary-to-hex or Base64) is also reversible, but it requires no secret — just knowledge of the defined mapping rules, which are typically public. Hashing, however, is a one-way function by design. There is no general algorithm to recover the original input from a hash digest; you can only attempt brute-force or dictionary attacks, not a true mathematical reversal. This makes A correct: encryption reversal requires an authorized key, encoding reversal requires the decoding rules (which are standardized and non-secret), and hashing has no general reversal operation. That cleanly and accurately describes all three. B is wrong because it falsely claims hashing requires a secret key to reverse — hashing uses no key at all in its basic form, and more importantly, it simply cannot be reversed. "Recomputing a checksum" is not how encoding reversal works either. C incorrectly swaps encryption and hashing — it claims encryption has no reversal (false; that's hashing's property) and that hashing requires an original key (hashing is keyless by default). D is wrong because it assigns a "secret key" requirement to encoding, which is never secret, and claims encryption needs only the public algorithm, ignoring the essential key requirement. A useful memory anchor: Encrypt = key, Encode = rules, Hash = one-way street. This trio appears frequently in security fundamentals questions.

Question 9

A client encrypts a message into arbitrary binary ciphertext and then Base64-encodes that ciphertext so it can be transmitted through a text-only protocol. The server receives the transmitted text without error.

Which sequence must the server normally perform to recover the message?

  1. Decrypt the Base64 text first, and then hash the result to reverse the text representation.
  2. Hash the Base64 text first, and then decrypt the digest using the sender's encryption key.
  3. Base64-encode the received text again, and then decrypt the resulting binary representation.
  4. Base64-decode the received text first, and then decrypt the recovered ciphertext with the proper key. (correct answer)
Explanation: When data travels through text-only protocols (like email or HTTP headers), raw binary ciphertext often contains bytes that those protocols can't handle. Base64 solves this by encoding arbitrary binary into safe ASCII characters. The key insight is that Base64 and encryption are independent, layered operations — and to reverse a stack of operations, you must undo them in reverse order. The client encoded last, so the server must decode first. That logic confirms D as correct. The server receives Base64 text, so it must first Base64-decode it to recover the original binary ciphertext — exactly what the client had before encoding. Only then does the server hold the actual ciphertext it can feed into the decryption algorithm with the proper key, recovering the plaintext message. A is wrong on two levels: you don't "decrypt first" when Base64 wraps the ciphertext (you'd be feeding ASCII text into a decryption function expecting binary), and hashing is a one-way function — it cannot reverse anything. Hashing destroys information by design. B commits the same hashing error. Hashing the Base64 text produces a fixed-length digest with no relationship to the original ciphertext. No key can "decrypt" a hash to recover plaintext; that's not what hashing does. C suggests re-encoding the already-encoded text, which moves you further away from the original binary — the opposite of what you need. Encoding again produces a doubly-encoded string, not ciphertext. Study tip: When a question describes layered operations, sketch the sender's steps in order, then mentally reverse that list — that's always the receiver's roadmap.

Question 10

A developer places an API token in an HTTP header after converting it to Base64. During testing, a packet capture reveals the Base64 value to an analyst, who immediately recovers the original token without possessing a key.

Which conclusion best explains the analyst's result?

  1. Base64 encrypted the token weakly, so the analyst recovered the plaintext by exploiting a short cryptographic key.
  2. Base64 encoded the token reversibly, so anyone knowing the encoding scheme could recover the original value. (correct answer)
  3. Base64 hashed the token deterministically, so the analyst reversed the digest using the published Base64 alphabet.
  4. Base64 encrypted the token symmetrically, so the HTTP header itself supplied the required decryption key.
Explanation: Whenever you see a question involving Base64, the critical distinction to make is between encoding, encryption, and hashing — three fundamentally different operations that are frequently confused. Base64 is a reversible encoding scheme, not a cryptographic one. It converts binary data into a set of 64 printable ASCII characters using a publicly known alphabet. Because the transformation is entirely deterministic and requires no secret key, anyone who recognizes the Base64 format can decode it instantly — no credentials, no key, no brute force required. This is exactly what the analyst did. Answer B is correct because it accurately identifies Base64 as an encoding mechanism whose reversal is trivially available to anyone with the scheme. A is wrong because Base64 is not encryption of any strength — weak or otherwise. Encryption, even poor encryption, requires a key. Base64 uses none. Calling it "weak encryption" is a categorical error, not just an understatement. C is wrong because hashing is a one-way function by design — digests cannot be "reversed." Base64 output is not a hash, and the Base64 alphabet is not a cryptographic construct that gets "exploited" to reverse a digest. D is wrong for a similar reason to A: Base64 is not symmetric encryption. The HTTP header supplies no decryption key because no encryption occurred in the first place. A reliable study tip: if a transformation requires no key and is publicly defined, it is encoding, not encryption. On security exams, Base64 is almost always presented as a trap that developers mistake for a security control — recognize it immediately.