SHA Comic Classroom Part 1: From Digital Fingerprints to Hardware Trust

That long hexadecimal string is a digest

The hexadecimal string beside a firmware download is a digest: a fixed-length value computed from the file. It does not conceal the original data or serve as a secret key. SHA stands for Secure Hash Algorithm.

SHA-256 always returns 256 bits, or 32 bytes. Written in hexadecimal, that is 64 characters. The abbreviated value in the plate is useful for a picture, but a real integrity check must compare the complete digest. ^[1]

A digest works as a digital fingerprint only if its expected value comes from a trusted source. If an attacker can replace both the file and the published digest, a plain comparison proves very little. A digital signature adds publisher authentication.

Different input lengths, one output length

A one-character message and a multi-gigabyte file both produce a 256-bit result under SHA-256. Because the input space is much larger than the output space, different inputs must sometimes produce the same digest; security depends on making those collisions infeasible to find.

Changing `Hello` to `hello` should radically change the digest. This avalanche behavior prevents an attacker from steering toward a target by making small input changes and watching for small output changes.

The same input under the same SHA algorithm always gives the same output. Raw SHA has no built-in salt or secret key. That is one reason raw SHA-256 is a poor password-storage function: it is deterministic and intentionally fast.

The three resistance properties answer different attacks

Preimage resistance asks whether an attacker, given only a target digest h, can find any message m such that H(m)=h. For an ideal n-bit hash, generic brute force is on the order of 2^n operations. ^[2]

Second-preimage resistance starts with a particular known message. The attacker must find a different message with the same digest. Collision resistance gives the attacker more freedom: choose any two different messages that collide.

Because the attacker may choose both inputs, a generic collision search reaches the birthday bound at roughly 2^(n/2). SHA-256 therefore has an ideal collision strength of about 128 bits even though its preimage strength is about 256 bits. ^[2]

The birthday paradox explains the square-root bound

In a room of 23 people, there are 253 pairs. The birthday problem counts every possible pair in the room, not matches against one predetermined birthday. The many pairings make a match appear surprisingly early.

Replace 365 birthdays with 2^n possible hash outputs. An attacker collecting many candidate messages gets many pairwise comparisons, so a collision becomes likely after about 2^(n/2) random-looking outputs.

A 128-bit digest therefore provides about 64 bits of ideal collision resistance; SHA-1's 160-bit output was designed around an 80-bit birthday bound, and SHA-256 targets about 128 bits of ideal collision resistance.

Merkle–Damgård turns a long message into a digest

SHA-1 and the SHA-2 family use an iterative structure. SHA-256 pads the message, includes its original length, splits the result into 512-bit blocks, and updates a 256-bit internal state block by block.

The relay-race picture captures the chaining rule: every compression step receives both the next message block and the state from the previous step. A change near the beginning therefore propagates through all later states.

This construction also creates a usage trap. Plain `SHA-256(secret || message)` can be vulnerable to length extension. SHA-384 and SHA-512/256 do not expose the full SHA-512-family internal state, so the standard attack used against SHA-256 does not transfer directly; SHA-3 uses a different sponge construction. These distinctions do not replace sound protocol design: message authentication should still use HMAC or another standardized authenticated construction. ^[1][5]

Hash algorithms have life cycles

MD2, MD4, and MD5 are Ronald Rivest's message-digest family. MD5 became ubiquitous, but practical collision attacks eventually made it unacceptable for applications that rely on collision resistance, including digital signatures. ^[6]

SHA-1 appeared during the same period but is not part of Rivest's MD family. It came from the U.S. standards process, has a 160-bit output, and shares the broad iterative design style of its era.

Systems need crypto agility: formats should identify their algorithms, software should remain updatable, and hardware trust chains should support migration to stronger hashes and signatures. Saving a small amount of area by freezing one algorithm forever can become an expensive system failure later.

SHAttered made a full SHA-1 collision real

In 2017, Google Research and CWI Amsterdam published two different PDF files with the same SHA-1 digest. SHAttered was a practical public collision for the full SHA-1 function. ^[4]

SHAttered did not recover messages from arbitrary SHA-1 digests. It broke collision resistance by producing two different files with the same digest. That result is devastating for workflows that treat the digest as a unique representative before signing or validating a document.

New security designs should not use SHA-1. NIST is transitioning away from SHA-1 for all cryptographic protection by the end of 2030. Legacy parsing may remain necessary, but reading old SHA-1 material is different from creating new trust with it. ^[3]

Five applications use hashes under different trust rules

File integrity compares a freshly computed digest with a trusted reference. Digital signatures hash a message before a private-key operation, but the signature scheme, key, certificate, and verification policy provide the authentication.

Password databases need a dedicated password hashing or key-stretching function such as Argon2id. A salt is necessary, but raw `SHA-256(password || salt)` is still too fast against large-scale guessing. ^[7]

HMAC combines a secret key and a hash in a standardized inner-and-outer construction. Merkle trees combine many leaf hashes into one root and support compact inclusion proofs. In both cases, SHA supplies one cryptographic building block; keys, proofs, and protocol rules provide the rest of the security. ^[5][8]

Hardware trust needs more than one hash comparison

A Secure Boot chain verifies each stage before transferring control. SHA compresses the candidate image into a digest; a trusted public key and digital-signature verification decide whether an authorized publisher signed it. ^[9]

OTP or eFuse and a PUF play complementary roles. OTP or eFuse may hold a root public-key hash, lifecycle state, anti-rollback version, debug policy, or other fixed configuration. A PUF can help reconstruct device-bound root material, which a KDF can separate into purpose-specific keys.

A PUF does not replace OTP, and it does not necessarily protect the OTP contents directly. Whether a PUF-derived key protects Secure Storage or other secret state depends on the product architecture.

Part 1 summary

SHA is hashing, not encryption. Its output length is fixed by the selected algorithm, and the three resistance properties describe different attacker goals. For an ideal n-bit output, collision search reaches a generic bound near 2^(n/2).

SHA-1's collision resistance has failed. Modern systems should choose an appropriate SHA-2, SHA-3, or other approved construction, while keeping room for future algorithm replacement.

Hashes support integrity checks, signatures, HMAC, KDFs, Merkle trees, and hardware roots of trust. The surrounding system still has to manage keys, salts, signatures, version rules, failure paths, and update mechanisms correctly.

Part 2 will examine the SHA-256 and SHA-512 rounds, message schedules, and hardware architectures, then compare the SHA-2 design with SHA-3's Keccak sponge.

References

1. NIST FIPS 180-4: Secure Hash Standard: The standard specification for SHA-1 and the SHA-2 family, including padding, block processing, and digest lengths.
2. NIST SP 800-107 Rev. 1: Guidance on preimage, second-preimage, and collision strength and on hash use in signatures, HMAC, and KDFs.
3. NIST: Transitioning Away from SHA-1 for All Applications: The official transition plan to remove SHA-1 from cryptographic protection by the end of 2030.
4. SHAttered: The 2017 Google Research and CWI Amsterdam project that published the first practical public collision for full SHA-1.
5. RFC 2104: HMAC: The standardized inner-and-outer keyed-hash construction for message authentication.
6. RFC 6151: Updated Security Considerations for MD5: Explains why MD5 is unacceptable where collision resistance is required and distinguishes MD5 from HMAC-MD5 use.
7. RFC 9106: Argon2: An implementer-oriented specification for a memory-hard password hashing function.
8. RFC 9162: Certificate Transparency Version 2.0: A concrete specification of Merkle trees, inclusion proofs, and consistency proofs.
9. NIST SP 800-193: Platform Firmware Resiliency Guidelines: Guidance for authenticated firmware updates, roots of trust, detection, protection, and recovery.