What is Hashing

A cryptographic hash function takes an input of any size and produces a fixed-length output (called a digest or hash) that acts as a unique fingerprint of that input. Change one bit of the input, and the output changes completely (avalanche effect). Critically, hashing is one-way: given a hash, you cannot compute the original input. This isn’t encryption — there’s no key, no decryption, no way back. Hashing proves integrity (“this data hasn’t been modified”) without revealing the data itself.

Why it matters

• Digital signatures — you don’t sign an entire document with RSA/ECDSA (too slow, size-limited). You hash the document to a fixed-size digest, then sign the hash. Verification: hash the document again, decrypt the signature, compare.
• Certificate integrity — every X.509 certificate includes a signature over its hash. If any field is modified after issuance, the hash changes and the signature becomes invalid.
• Password storage — passwords are stored as hashes (bcrypt, argon2), not plaintext. Authentication: hash the submitted password and compare to the stored hash. Compromise of the database doesn’t reveal passwords directly.
• Data integrity — file downloads include checksums (SHA-256 hashes). After downloading, you hash the file locally and compare. Match = file wasn’t corrupted or tampered with in transit.
• Merkle trees — Certificate Transparency logs, blockchain, and Git all use hash trees to efficiently prove data integrity across large datasets.

How it works

1. Input — any data of any length (a single byte, a 10GB file, or an empty string)
2. Processing — the hash function processes the input through multiple rounds of mathematical operations (bitwise operations, modular addition, compression functions)
3. Output — a fixed-size digest:
   • SHA-256: 256 bits (32 bytes) — e3b0c44298fc1c149afbf4c8996fb924...
   • SHA-384: 384 bits (48 bytes)
   • SHA-512: 512 bits (64 bytes)
4. Properties guaranteed:
   • Deterministic — same input always produces same output
   • Avalanche — tiny input change produces completely different output
   • Pre-image resistance — can’t find input from output
   • Collision resistance — can’t find two different inputs with the same output

In real systems

Certificate signature verification:

# View the signature algorithm used in a certificate
openssl x509 -in cert.pem -noout -text | grep "Signature Algorithm"
# Output: Signature Algorithm: sha256WithRSAEncryption
# Means: SHA-256 hash of the certificate, signed with RSA

# Compute certificate fingerprint
openssl x509 -in cert.pem -noout -fingerprint -sha256
# SHA256 Fingerprint=A1:B2:C3:D4:...

File integrity verification:

# Generate checksum
sha256sum firmware-v2.1.bin > firmware.sha256

# Verify after download
sha256sum -c firmware.sha256
# firmware-v2.1.bin: OK

Git commit integrity:

# Every Git commit is identified by a SHA-1 hash of its contents
git log --oneline
# a1b2c3d Fix certificate renewal logic
# The hash covers: tree, parent, author, committer, message
# Any modification changes the hash — tampering is detectable

HMAC (Hash-based Message Authentication Code):

# HMAC combines a hash with a secret key for authenticated integrity
echo -n "message" | openssl dgst -sha256 -hmac "secret-key"
# Proves both integrity AND authenticity (only someone with the key can produce valid HMAC)

Where it breaks

SHA-1 collision (2017) — Google and CWI Amsterdam demonstrated a practical SHA-1 collision (two different PDF files with the same SHA-1 hash). This means SHA-1 can no longer guarantee that two different documents won’t produce the same hash. All CAs stopped issuing SHA-1 certificates in 2016. If you still have SHA-1-signed certificates in your infrastructure, they’re rejected by modern browsers and represent a security gap.

Hash without authentication — a hash alone proves integrity but not authenticity. An attacker who modifies a file can also recompute and replace the hash. You need either: a signed hash (digital signature), an HMAC (hash with a shared secret), or the hash delivered over a separate trusted channel. Checksums on the same download page as the file provide minimal security — if the server is compromised, both file and checksum are replaced.

Length extension attacks — naive constructions like hash(secret + message) using SHA-256 are vulnerable to length extension attacks (attacker can compute hash(secret + message + attacker_data) without knowing the secret). This is why HMAC exists — it uses a specific construction (hash(key XOR opad || hash(key XOR ipad || message))) that prevents this attack. Never roll your own MAC from raw hash functions.

Operational insight

In the certificate ecosystem, the hash algorithm in the signature is the weakest link in the chain. A certificate signed with sha256WithRSAEncryption is only as collision-resistant as SHA-256. When SHA-1 was broken, every SHA-1-signed certificate became theoretically forgeable — an attacker could create a different certificate with the same hash, and the CA’s signature would validate for both. This is why the industry migrated to SHA-256 years before a practical attack was demonstrated. The lesson: hash algorithm transitions in PKI take years (every certificate must be re-issued), so migration must start well before the algorithm is fully broken.

Related topics

• Digital Signatures
• What is Symmetric Encryption
• What is Asymmetric Encryption
• What are Cipher Suites
• What is a TLS Certificate