What is a Hash Function? Understanding Cryptographic Hashing

Input → Hash Function → Output (Hash)

"hello" → SHA-256 → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

"Hello" → SHA-256 → 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
(Notice: Small change = completely different hash)

"This is a very long message with lots of text" → SHA-256 → 
64 characters (256 bits / 4 bits per hex char)

Key Properties:
1. Same input always produces same hash
2. Small change in input = completely different hash
3. Fixed output size regardless of input size
4. One-way: can't reverse hash to get input
5. Fast to compute

Deterministic:
"hello" always → 2cf24dba5fb0a30e...

Avalanche Effect (small change → huge difference):
"hello"  → 2cf24dba5fb0a30e...
"Hello"  → 185f8db32271fe25...

Fixed Size:
SHA-256 always outputs 256 bits (64 hex chars)
MD5 always outputs 128 bits (32 hex chars)

One-Way (Pre-image Resistance):
Given hash, can't find original input

Collision Resistance:
Very hard to find two inputs with same hash

Output: 32 hexadecimal characters (128 bits)
Speed: Very fast
Security: BROKEN - Do not use for security

Example:
"hello" → 5d41402abc4b2a76b9719d911017c592

Problems:
- Collision attacks possible (since 2004)
- Can find two different inputs with same hash
- Not suitable for passwords or security

Still used for:
- Non-security checksums
- File integrity (when security not critical)
- Legacy systems

Output: 40 hexadecimal characters (160 bits)
Speed: Fast
Security: DEPRECATED - Avoid for new systems

Example:
"hello" → aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

Problems:
- Collision attacks demonstrated (2017)
- Major companies phasing out (Google, Microsoft)
- Not recommended by security agencies

Legacy use:
- Git commits (being phased out)
- Older TLS certificates
- Some file verification

Output: 64 hexadecimal characters (256 bits)
Speed: Fast enough for most uses
Security: SECURE (current standard)

Example:
"hello" → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Advantages:
+ No known practical attacks
+ Widely supported and tested
+ Government/military approved
+ Used in Bitcoin and blockchain

Recommended for:
- Password hashing (with salt)
- Digital signatures
- Certificate generation
- Data integrity verification
- Cryptocurrency

Output: 128 hexadecimal characters (512 bits)
Speed: Slower than SHA-256
Security: VERY SECURE

Example:
"hello" → 9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043

When to use:
- Maximum security needed
- Large data integrity
- Long-term data protection
- 64-bit systems (optimized for)

bcrypt (for passwords):
- Adaptive: can increase difficulty over time
- Includes salt automatically
- Designed to be slow (prevent brute force)

scrypt (for passwords):
- Memory-hard (requires lots of RAM)
- Resistant to GPU/ASIC attacks

Argon2 (modern password hashing):
- Winner of Password Hashing Competition
- Configurable memory, time, parallelism

BLAKE2/BLAKE3:
- Faster than SHA-2
- As secure as SHA-3
- Modern, efficient design

Collision Example:
Input A: "hello"
Input B: "world" 
If hash(A) == hash(B), that's a collision

Why collisions exist:
- Infinite possible inputs
- Finite hash outputs (e.g., 2^256 for SHA-256)
- Pigeonhole principle: must exist theoretically

Practical concern:
- MD5: Easy to find collisions (insecure)
- SHA-1: Possible but expensive (deprecated)
- SHA-256: Computationally infeasible (secure)

Birthday Paradox:
With n-bit hash, expect collision after ~2^(n/2) hashes
SHA-256: 2^128 hashes needed (practically impossible)

Problems with plain SHA-256 for passwords:

1. Too Fast:
   Attackers can try billions of passwords/second
   
2. Rainbow Tables:
   Pre-computed hashes of common passwords
   SHA-256("password") always same → easy lookup
   
3. No Salt:
   Same password = same hash
   "password" → same hash for all users

Better approach: Use bcrypt, scrypt, or Argon2
These are designed specifically for passwords!

Without salt (BAD):
User A password: "hello" → hash1
User B password: "hello" → hash1 (same!)

With salt (GOOD):
User A: "hello" + salt1 → unique_hash1
User B: "hello" + salt2 → unique_hash2 (different!)

Salt is random and stored with hash:
Stored: salt1 + hash1

Verification:
1. Get user's salt from database
2. Hash input password with that salt
3. Compare with stored hash

// bcrypt (Node.js example)
const bcrypt = require('bcrypt');
const saltRounds = 10;

// Hash password
const hash = await bcrypt.hash('myPassword', saltRounds);
// $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

// Verify password
const match = await bcrypt.compare('myPassword', hash);

Features:
- Automatic salt generation
- Adaptive (can increase difficulty)
- Slow by design (good for passwords)
- Industry standard

Scenario: Download Ubuntu ISO

1. Download file: ubuntu.iso (4GB)
2. Check official hash: 
   SHA-256: a1b2c3d4...
   
3. Generate hash of downloaded file:
   sha256sum ubuntu.iso
   Output: a1b2c3d4...
   
4. Compare:
   If match: File is authentic and uncorrupted
   If different: File corrupted or tampered with

Commands:
macOS:   shasum -a 256 file.iso
Linux:   sha256sum file.iso
Windows: certutil -hashfile file.iso SHA256

Git uses SHA-1 (moving to SHA-256) for:

Commit ID:
git log
commit a1b2c3d4e5f6... (hash of commit content)

File tracking:
Git stores files by content hash
Same content = same hash = deduplicated

Integrity:
Changing history changes all subsequent hashes
Makes tampering detectable