Cryptographic Hashing: SHA-256
You'll learn to
- -Contrast a cryptographic hash function's guarantees with a hashmap's hash function
- -Explain one-wayness, collision resistance, and the avalanche effect
- -Identify real uses of cryptographic hashing: password storage, integrity checks, blockchains
You have used hashing since the hashmap tier: a hash function turns a key into a number so you can index into a bucket array in O(1). That hash function has one job - spread keys out to minimize collisions - and nothing about it needs to be secret or hard to reverse; in fact a hashmap's hash for small integers is often just the integer itself. Level 30 introduces a completely different flavor of hash function, one built for security rather than speed of lookup: SHA-256.
Three Guarantees a Hashmap's Hash Never Needed
- -One-way (preimage resistance): given a hash output, there is no feasible way to compute an input that produces it, other than trying inputs one by one.
- -Collision resistant: it is computationally infeasible to find two different inputs that produce the same output - unlike a hashmap, where collisions are expected and just handled with chaining or probing.
- -Deterministic and fixed-size: the same input always produces the same output, and every output is 256 bits regardless of input size - hashing one byte or one gigabyte both produce a digest of the exact same length.
The Avalanche Effect
Change a single bit of the input and the output should change unpredictably and completely - roughly half the output bits flip, with no discernible relationship to which input bit changed. That property, called the avalanche effect, is what makes a hash useful as an integrity check: if a file's SHA-256 digest matches the expected value, you know the file is byte-for-byte identical to what produced that digest, because even a one-character edit would have produced a wildly different hash.
Where This Actually Gets Used
- -Password storage: never store a password directly - store a salted hash of it, so a database breach does not hand out plaintext passwords.
- -Integrity verification: software downloads publish a SHA-256 checksum so you can confirm the file was not corrupted or tampered with in transit.
- -Blockchains: each block includes the hash of the previous block, so tampering with any historical block changes its hash and breaks every subsequent link.
- -Content-addressed storage, like Git: objects are named by the hash of their content, so identical content always gets the same, verifiable name.
Never confuse a cryptographic hash (SHA-256) with a password hashing function (bcrypt, scrypt, Argon2). SHA-256 is deliberately fast, which is exactly wrong for passwords - fast means an attacker's brute-force guessing is fast too. Password hashers are deliberately slow and salted.
Why can't you just reverse a SHA-256 hash to recover the original input if you need to check a password?
"Because it's encrypted."
"It's not encryption, it's a one-way hash - there's no mathematical inverse operation, only brute force. That's by design: preimage resistance means given a hash, you cannot feasibly compute an input that produces it. So systems store the hash of a password and, on login, hash the entered password again and compare hashes - the plaintext password is never stored or needed again after the check."
What is the key difference between a hashmap's hash function and a cryptographic hash function like SHA-256?
Level 30: SHA-256 Sentinel has you work directly with cryptographic hashing and verify its properties - determinism, one-wayness, and the avalanche effect - the same guarantees that make it usable for password storage, integrity checks, and blockchains.