A checksum is a short value calculated from a block of data so you can later recompute it and check whether the data was altered or corrupted. It verifies integrity, but unlike encryption it does not hide the data.
A checksum is a small value you generate by running data through an algorithm. The point is integrity: if even one bit of the original data changes, recomputing the checksum gives a different result, so you know something got altered or corrupted. Think of it like a tamper seal on a package. The seal doesn't lock the box or hide what's inside; it just tells you whether someone opened it.
This is where checksums sit next to the cryptography ideas in Topic 5.3. Encryption (covered in EK 5.3.A) is about hiding information so unauthorized people can't read it. A checksum does something different. It doesn't scramble the data or use a secret key to keep it private. It produces a fingerprint you can compare later. In practice, cryptographic hash functions like SHA-256 are used to create strong checksums, because a good hash makes it extremely hard for two different inputs to produce the same output (that property is called collision resistance).
Checksums live in Unit 5: Securing Applications and Data, alongside Topic 5.3 on protecting stored data with cryptography. The learning objectives there (AP Cybersecurity 5.3.A and 5.3.B) center on encryption, which protects confidentiality. A checksum rounds out the picture by handling a different security goal: integrity. Knowing the difference is exactly the kind of distinction the exam rewards, because confidentiality and integrity are separate jobs and one tool rarely does both. When you can say "encryption hides it, a checksum proves it wasn't changed," you've got the conceptual split the CED is built on.
Keep studying AP Cybersecurity Unit 5
Visual cheatsheet
view galleryCryptographic hash function (Unit 5)
A modern, secure checksum IS a cryptographic hash. When you run a file through SHA-256 and compare the output, you're using a hash as a checksum. The hash gives the integrity check its strength.
Encryption (Unit 5)
Encryption and checksums solve opposite halves of the same problem. Encryption keeps data secret; a checksum confirms data stayed the same. You often use both together, encrypt for privacy, checksum for integrity.
Collision resistance (Unit 5)
A checksum is only trustworthy if two different inputs almost never produce the same output. That's collision resistance. Weak algorithms like MD5 and SHA-1 lose this property, which is why they're no longer safe for integrity checks.
SHA-256 (Unit 5)
SHA-256 is the go-to algorithm for generating reliable checksums today. Software downloads list a SHA-256 value so you can recompute it and confirm the file arrived intact and untampered.
Expect checksums to show up in questions that test whether you understand the difference between security goals. A multiple-choice stem might describe a scenario (a downloaded file, a transmitted message) and ask what a checksum actually protects against, where the right answer is corruption or tampering, not eavesdropping. No released FRQ uses the word "checksum" verbatim, but the integrity-versus-confidentiality distinction it represents is exactly the kind of reasoning a free-response question on protecting data could ask you to apply. Be ready to name a real algorithm (SHA-256) and explain why a weak one (MD5, SHA-1) makes a checksum unreliable.
Encryption hides data so unauthorized people can't read it, and it's reversible with the right key (you decrypt to get the plaintext back). A checksum doesn't hide anything and isn't meant to be reversed; it's a one-way fingerprint you recompute to check for changes. If your goal is privacy, you want encryption. If your goal is detecting tampering or corruption, you want a checksum.
A checksum verifies integrity by detecting whether data has changed, but it does not hide the data the way encryption does.
A secure checksum is built from a cryptographic hash function like SHA-256, not from encryption.
Change even one bit of the input and the checksum changes, which is how you catch corruption or tampering.
Weak algorithms like MD5 and SHA-1 fail collision resistance, so they make untrustworthy checksums.
Encryption protects confidentiality and a checksum protects integrity; they are different security goals you often use together.
A checksum is a small value computed from data so you can recompute it later and confirm the data hasn't been altered or corrupted. Its job is integrity, meaning it tells you whether the data changed, not whether anyone could read it.
No. A checksum does not hide or scramble anything. It produces a fingerprint of the data for comparison. If you need the data kept secret, you need encryption (Topic 5.3), which uses a key and is reversible through decryption.
Encryption hides information and can be reversed with the right key. A checksum is a one-way value you can't reverse, used only to detect changes. Encryption handles confidentiality; a checksum handles integrity.
A modern secure checksum is essentially a cryptographic hash. Running a file through SHA-256 to verify it is using a hash as a checksum. The hash function's collision resistance is what makes the checksum trustworthy.
Because they've lost collision resistance, meaning attackers can find two different inputs that produce the same output. That breaks the whole point of a checksum, so SHA-256 is preferred for reliable integrity checks.
Connect this key term to the AP exam workflow: review the course, practice questions, and check related study tools.