- What does the administrator's successful comparison establish in this situation?
Answer: It shows consistency with the posted digest, but not authenticity because the attacker controlled both values.
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.
- Which processing approach most directly satisfies both requirements?
Answer: Encrypt each report for confidentiality and retain a cryptographic hash of each plaintext report for later corruption detection.
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.
- Which analysis most accurately addresses the developer's claim?
Answer: The replacement is encoding for transport syntax and can be reversed without a secret, so it provides no confidentiality.
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.
- Which assessment of this design is most accurate?
Answer: The plaintext hashes can reveal duplicate groups, although they also expose equality information about the documents.
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).
- Which statement best evaluates replacing each identifier with an unsalted cryptographic hash?
Answer: It supports consistent grouping, but predictable identifiers may still be discovered by hashing every likely candidate.
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.
- Which response is most accurate?
Answer: The hashes are not decrypted; investigators can only test password guesses by hashing each guess with the relevant salt.
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.
- Which statement correctly distinguishes the three transformations?
Answer: Encryption normally requires an authorized key to reverse, encoding requires the defined decoding rules, and hashing has no general reversal operation.
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.
- Which sequence must the server normally perform to recover the message?
Answer: Base64-decode the received text first, and then decrypt the recovered ciphertext with the proper key.
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.
- Which conclusion best explains the analyst's result?
Answer: Base64 encoded the token reversibly, so anyone knowing the encoding scheme could recover the original value.
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.
- Which interpretation of the processing steps is most accurate?
Answer: 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.
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.
