Study guide

13.3 Hashing, MACs & Integrity

U.S. Air Force Cyber Test CSAT/ICTL

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Cyber AFSCs & Qualification Pipeline 1.3 How to Use This Guide & Study Plan

2 Number Systems & Encoding

2.1 Binary & Decimal Conversion 2.2 Hexadecimal & ASCII 2.3 Bitwise Operations & Two's Complement

3 Computing Architecture

3.1 Memory Hierarchy 3.2 CPU, Components & Data Path 3.3 Core Data Structures

4 Boolean Logic & Storage

4.1 Boolean Algebra & Logic Gates 4.2 Encoding, Files & Storage Concepts

5 Networking Models

5.1 OSI Model 5.2 TCP/IP Model & Encapsulation 5.3 Topologies & Transmission Media

6 Addressing & Subnetting

6.1 IPv4 Addressing 6.2 Subnetting & CIDR 6.3 IPv6 Fundamentals

7 Protocols & Network Services

7.1 TCP, UDP & Well-Known Ports 7.2 DNS & DHCP 7.3 Routing & Switching Basics

8 Cybersecurity Foundations

8.1 CIA Triad & Security Goals 8.2 Threats, Vulnerabilities & Malware 8.3 Social Engineering & Human Factors

9 Defensive Controls

9.1 Access Control & Authentication 9.2 Firewalls, IDS & IPS 9.3 SIEM & Defense in Depth

10 Programming Fundamentals

10.1 Variables, Types & Operators 10.2 Control Flow 10.3 Functions & Recursion

11 Languages & Debugging

11.1 Python Essentials for the Cyber Test 11.2 C++ Basics & Debugging Concepts

12 Operating Systems

12.1 Linux Fundamentals & Commands 12.2 Windows Fundamentals 12.3 Processes, Permissions & File Systems

13 Cryptography

13.1 Symmetric Encryption (AES) 13.2 Asymmetric Crypto & PKI 13.3 Hashing, MACs & Integrity

14 ICTL-Style Logic Reasoning

14.1 Deductive Logic & Syllogisms 14.2 Sequences & Pattern Recognition 14.3 Arrangement & Conditional Puzzles

15 Test Strategy & Mixed Review

15.1 Pacing, Elimination & AF Testing Day 15.2 Mixed Domain Review & Next Steps

13.3 Hashing, MACs & Integrity

Key Takeaways Explain This Topic AI

A cryptographic hash is deterministic, one-way, and avalanche-sensitive: the same input always yields the same digest, but the digest should not reveal the input, and tiny input changes scramble the output

SHA-256 is a widely used modern hash producing a 256-bit digest for integrity checks, fingerprinting, and as a building block inside signatures and HMACs

Hashing is not encryption — there is no key that ‘decrypts’ a digest back to the original message

MACs/HMACs use a shared secret plus a hash construction to detect tampering and prove the message came from a key holder; encryption alone does not guarantee integrity

Password storage should use slow, salted password hashing (or equivalent KDFs), not reversible encryption and not a fast raw hash of the password alone

Last updated: July 2026

Encryption protects confidentiality . Many cyber problems instead ask: “Was this data altered?” or “Is this the same file I downloaded yesterday?” Those are integrity questions. Cryptographic hash functions , MACs , and HMACs are the core tools. This section also covers why password storage uses specialized hashing — a frequent conceptual trap when candidates confuse hashing with encryption.

What a Cryptographic Hash Does

A cryptographic hash function takes an arbitrary-length input (a password, a firmware image, a network packet payload) and produces a fixed-length output called a digest or hash value . For Cyber Test reasoning, lock in three properties:

Deterministic. The same input always produces the same digest. If SHA-256("flight-plan.txt") is computed twice on identical bytes, the results match. That is why hashes can verify downloads: publish the digest; recompute locally; compare.

One-way (preimage resistance). Given only the digest, it should be computationally infeasible to recover a useful original input. You cannot “decrypt” a hash — there is no decryption key because hashing is not encryption.

Avalanche effect. A tiny change in the input — one flipped bit — should produce a drastically different digest. That sensitivity makes accidental or malicious modifications obvious when digests are compared.

Related goals you may see named in study materials: collision resistance (it should be hard to find two different inputs with the same digest) and second-preimage resistance (given one input, it should be hard to find a different input with the same digest). You do not need formal security proofs; you need the operational meaning: matching digests strongly suggest identical inputs; mismatched digests prove a change.

SHA-256 in Practice

SHA-256 (part of the SHA-2 family) produces a 256-bit digest, usually shown as 64 hexadecimal characters. It is a modern default for:

File and firmware integrity verification.

Fingerprints of certificates and keys (human-comparable digests).

Building blocks inside digital signatures (sign the hash of a message, not the entire multi-megabyte message).

Building blocks inside HMAC constructions.

Older algorithms such as MD5 and SHA-1 are considered broken or unsafe for collision-resistant uses; prefer SHA-256 (or stronger SHA-2/SHA-3 variants) in modern guidance. For the exam, associating SHA-256 with “strong, common integrity hash” is the main payoff.

Example mental check: if a vendor posts SHA256: 3a7f… next to an ISO download and your computed digest differs, do not install the image — integrity failed, regardless of whether the download “looked” complete.

Hashing Is Not Encryption

This distinction is heavily tested:

  • Hashing Encryption
  • Goal Integrity / fingerprinting Confidentiality
  • Reversible? No (one-way) Yes, with the correct key
  • Key required? No for a plain hash Yes (symmetric or asymmetric)
  • Output size Fixed (e.g., 256 bits) Roughly related to plaintext size (plus overhead)

Storing “encrypted passwords” by running them through SHA-256 alone is a misuse of language and often a misuse of cryptography. A digest is not ciphertext. Conversely, encrypting a file with AES does not by itself prove the ciphertext was unmodified in transit unless you also use an integrity mechanism (MAC, AEAD tag, signed hash, and so on).

MACs and HMACs: Integrity With a Shared Secret

A plain hash answers “does this match the published digest?” Anyone who can modify a file can also recompute and republish a new hash if they control the channel where the hash is posted. When two parties share a secret and need to detect tampering on messages they exchange, they use a Message Authentication Code (MAC) .

A MAC takes message + secret key and produces an authentication tag. The receiver recomputes the tag with the same key and compares. If the tags match, the message was not altered and was produced by someone who knows the key (within the MAC’s security model).

HMAC is a specific, widely standardized way to build a MAC from a cryptographic hash (for example HMAC-SHA-256). You will see HMAC in APIs, TLS-related constructions historically, and secure token designs. Key points:

MAC/HMAC provides integrity and authenticity relative to a shared key .

MAC/HMAC does not encrypt the message; the message may still be readable unless separately encrypted.

Encryption without integrity can leave room for certain manipulation attacks depending on mode; modern systems prefer authenticated encryption or explicit MACs.

Compare roles quickly:

AES encrypt → hide contents.

SHA-256 hash → fingerprint contents (no secrecy of the fingerprint process itself).

HMAC-SHA-256 → prove a keyed party produced this exact content.

Digital signature (asymmetric) → prove a specific private-key holder signed the content; verifiable with a public key / certificate (no shared MAC key required between verifier and signer).

Password Hashing Intuition

User passwords should not be stored in plaintext. They also should not be stored with reversible encryption if the goal is “even the database thief cannot easily recover passwords.” Best practice uses password hashing / key-derivation functions designed to be:

One-way , so the stored value is a verifier, not the password.

Salted , so identical passwords for different users do not produce identical stored hashes, blocking precomputed rainbow-table reuse across users.

Slow / memory-hard (intentionally expensive), so online and offline guessing is costly — unlike fast SHA-256 alone, which GPUs can try at enormous rates.

Algorithms in this family (bcrypt, scrypt, Argon2, PBKDF2-style constructions) are password-oriented. The Cyber Test may not demand a specific algorithm name, but it will expect the intuition: passwords → slow salted password hash , not “AES-encrypt the password with a key sitting next to the database,” and not “raw unsalted SHA-256 of the password.”

When a user logs in, the system hashes the offered password with the same salt/parameters and compares verifiers — it does not decrypt a password back to plaintext.

Integrity Workflows You Should Recognize

Software supply chain: vendor publishes SHA-256 sums; admins verify before install.

Secure messaging/storage: encrypt for confidentiality, MAC or AEAD for integrity.

Authentication tokens / API requests: HMAC tags prove a request was not altered and came from a key holder.

Forensics / evidence handling: hashing disk images documents that evidence was not changed later.

If a question emphasizes “detect change” or “verify identical file,” think hash . If it emphasizes “detect change using a shared secret between two parties,” think MAC/HMAC . If it emphasizes “hide contents,” think encryption . Keeping those three lanes separate is the highest-yield study strategy for this section.