Explain how hashing, checksums and authentication are used to verify the integrity and authenticity of data during storage and transmission

What this dot point is asking

The encryption dot point covers keeping data secret. This dot point covers a different goal: proving data has not changed and confirming who or what it came from. QCAA groups hashing and checksums with secure data handling because they verify integrity (the data is unaltered) and support authentication (the data is from who it claims). Hashing is not encryption, and the distinction is heavily examined, so this page treats integrity verification on its own terms.

What a hash function is

A hash function takes input of any size and produces a fixed-length output called a hash, digest or message digest. Key properties:

• Deterministic: the same input always gives the same hash.
• Fixed length: a one-character input and a one-gigabyte file both produce a hash of the same size.
• One-way: you cannot reverse a hash to recover the input.
• Avalanche effect: changing one bit of input changes much of the hash, so tampering is obvious.

Common cryptographic hash functions include SHA-256. Older functions like MD5 are considered broken for security use because collisions can be engineered.

Checksums and error detection

A checksum is a value computed from data and sent alongside it, so the receiver can recompute it and compare. If the two differ, the data changed in transit, usually through accidental corruption such as a dropped bit. Checksums are built into network protocols like TCP to detect transmission errors and trigger retransmission. They are simple and fast but designed for accidental errors, not deliberate tampering, because an attacker could alter the data and the checksum together.

Hashing for integrity in data exchange

When two systems exchange data, the sender can compute a hash of the payload and send it too. The receiver recomputes the hash and compares. A match proves integrity: the data is exactly what was sent. To also prove authenticity (who sent it), systems use a keyed hash or a digital signature, which combines hashing with the asymmetric keys from the encryption dot point so only the genuine sender could have produced the value.

Hashing for password storage

Systems should never store passwords in plain text. Instead they store the hash. At login, the system hashes the entered password and compares it to the stored hash; a match means the password was correct without the system ever keeping the original. Good practice adds a unique random salt to each password before hashing, so identical passwords produce different hashes and precomputed attack tables fail. This is a frequent exam scenario and a strong security feature to justify in IA3.

Hashing versus encryption

This distinction earns marks:

• Encryption is two-way: data is transformed with a key and can be decrypted back to the original. Its goal is confidentiality.
• Hashing is one-way: there is no key to reverse it. Its goal is integrity and verification.

You encrypt data you need to read again; you hash data you only need to verify, like a password or a file's fingerprint.

How this appears in assessment

The external exam can ask you to explain how hashing verifies integrity, how passwords should be stored, or how hashing differs from encryption. In IA3 you justify hashing passwords and verifying the integrity of exchanged data. Be ready to describe the recompute-and-compare process and to state clearly why hashing is one-way.