A records clerk proposes hashing archived city council minutes so the files stay confidential yet can be opened and read later. Why is that proposal incorrect?
Select an answer to reveal the explanation.
Short Explanation
A hash is a fingerprint, not a lockbox. Once you turn minutes into a digest, you cannot unwind that digest back into the readable PDF—so hashing will not keep a confidential archive you plan to open later.
Full Explanation
Cryptographic hashing produces a fixed-size digest that supports integrity verification: changing even one byte of city council minutes yields a different digest. The transform is intentionally one-way, so the digest cannot be inverted to reconstruct the readable PDF or other archive. A clerk who needs confidential records that remain openable later requires encryption (or equivalent reversible access control over ciphertext), not hashing. Hashing the minutes therefore fails the confidentiality-plus-later-readability goal by design.
Saying hashing is only for wireless passwords is false; hashing applies to files, messages, software packages, and password verifiers alike—the misuse here is purpose, not file type. Claiming hashing always expands files is incorrect; digests are typically much smaller than the input and are stored or transmitted alongside content, not as a replacement archive format. Asserting hashing alone grants non-repudiation without signing keys confuses integrity fingerprints with digital signatures; non-repudiation generally needs private-key signing plus verification context.
Exam caveat: hashing equals integrity (and one-way password storage patterns), not confidentiality of recoverable documents. Operational check: for municipal records that must stay secret yet retrievable, use approved encryption and key management; use hashes to detect tampering of published or archived packages, and never treat a digest as a lockbox for documents staff must reopen.