Applied Cryptography Lab: The Avalanche Effect, Symmetric AES-GCM vs RSA, and Key Derivation
Demonstrate why fast hash functions (SHA-256) are dangerous for password storage, visualize cryptographic diffusion through the Avalanche Effect, and encrypt data securely with AES-256-GCM using unique Initialization Vectors (IVs).
1. Production Scenario & Incident
A startup was storing user passwords hashed with raw SHA-256. When an adversary dumped the database, they cracked 85% of user passwords within two hours using commodity GPU cracking rigs (hashcat). Furthermore, the company's database encryption reused the exact same 96-bit AES-GCM IV across all rows, enabling attackers to recover plaintext messages without the key. You must analyze the cryptographic failures, implement salt-based Argon2id hashing, and properly generate unique IVs for AES-GCM.
2. Architectural Background & RFC Standards
Applied cryptography provides four security pillars: Confidentiality (encryption), Integrity (MACs), Authentication (digital signatures), and Non-repudiation. Understanding the mathematical distinction between message digests, password KDFs, and authenticated ciphers is vital for security engineering.
- The Avalanche Effect: A hallmark of cryptographically secure hash functions where flipping a single input bit changes approximately 50% of the output bits in an unpredictable manner.
- Speed vs Work Factor: General hash functions (SHA-256, BLAKE3) are designed to be extremely fast (billions of hashes/sec on GPUs), making them lethal for passwords. Password KDFs (Argon2id, bcrypt, PBKDF2) are deliberately slow and memory-hard.
- Authenticated Encryption (AEAD): AES-GCM provides both confidentiality and tamper-proof authentication tags. Reusing an IV with the same key destroys the authentication guarantee and leaks XORed plaintext.
- Initialization Vectors (IV / Nonce): Must be unique for every single encryption operation using a given key.
3. Hands-On Lab Instructions
Use the interactive Avalanche visualizer below: enter two strings differing by only 1 character (e.g., "Pass1" vs "Pass2").
Observe the 256-bit heatmap showing how ~128 bits flip completely across the two SHA-256 digests.
Benchmark how fast a GPU computes SHA-256 vs how Argon2id consumes memory and CPU iterations.
Encrypt a message using AES-256-GCM in the Web Crypto API workbench with a 96-bit cryptographically random IV.
Verify that altering any single byte of ciphertext causes AES-GCM decryption to throw an authentication tag mismatch error.
4. Interactive Lab Workbench
Modify input characters in real-time to watch SHA-256 output bits flip. Test AES-GCM authenticated encryption and tamper detection.
Optimal cryptographic diffusion target is ~50% (128 of 256 bits).
5. Diagnostic Comprehension Questions
Why is plain SHA-256 or MD5 completely inappropriate for password hashing, even with a salt?
Reveal Answer & Explanation →
✓ Correct Answer: SHA-256 is designed for extreme computational speed; a single modern consumer GPU can compute over 10 billion SHA-256 hashes per second, making brute-force cracking trivial.
Cryptographic hash functions like SHA-256 prioritize throughput for validating gigabytes of files and network packets. Password hashing requires intentionally slow, memory-hard Key Derivation Functions (KDFs) like Argon2id or bcrypt that neutralize GPU and ASIC parallelized cracking.
What catastrophic security failure occurs if you reuse the same 96-bit Initialization Vector (IV) twice with the same AES-GCM key?
Reveal Answer & Explanation →
✓ Correct Answer: Attackers can XOR the two ciphertexts together to eliminate the keystream and recover the underlying plaintexts, as well as forge authentication tags.
AES-GCM operates in Counter (CTR) mode with a GMAC authentication tag. If an IV is repeated with the same key, identical keystream blocks are generated. XORing the two ciphertexts cancels out the keystream, exposing the XOR of the plaintexts and allowing cryptographic forgery of valid auth tags.
6. Progressive Diagnostic Hints
💡 Hint #1▼
💡 Hint #2▼
💡 Hint #3▼
7. Verified Production Solution
Replace raw SHA-256 password hashing with Argon2id using unique 16-byte salts, and implement AES-256-GCM authenticated encryption with cryptographically random 96-bit IVs generated per message.
// Modern Secure Cryptography in Node.js (Crypto & Web Crypto API)
import crypto from 'node:crypto';
// 1. SECURE PASSWORD HASHING WITH ARGON2id (or Scrypt / Bcrypt)
export async function hashPassword(password: string): Promise<string> {
const salt = crypto.randomBytes(16);
// Argon2id or scrypt with memory cost
return new Promise((resolve, reject) => {
crypto.scrypt(password, salt, 64, { N: 16384, r: 8, p: 1 }, (err, derivedKey) => {
if (err) reject(err);
// Format: salt:derivedKey
resolve(salt.toString('hex') + ':' + derivedKey.toString('hex'));
});
});
}
// 2. SECURE SYMMETRIC ENCRYPTION WITH AES-256-GCM
export function encryptAesGcm(plaintext: string, keyBuffer: Buffer) {
// 96-bit (12 bytes) IV: MUST BE UNIQUE PER OPERATION
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', keyBuffer, iv);
let ciphertext = cipher.update(plaintext, 'utf8', 'hex');
ciphertext += cipher.final('hex');
// 128-bit Authentication Tag
const authTag = cipher.getAuthTag();
// Transmit IV + AuthTag + Ciphertext
return {
iv: iv.toString('hex'),
tag: authTag.toString('hex'),
ciphertext
};
}- ✓1. Never use raw SHA-256, SHA-512, or MD5 for passwords. Use memory-hard algorithms like Argon2id or Scrypt.
- ✓2. Generate a 16-byte cryptographically secure random salt per password using `crypto.randomBytes(16)`.
- ✓3. For data-at-rest encryption, use an authenticated cipher mode like AES-256-GCM or ChaCha20-Poly1305.
- ✓4. Always generate a fresh 96-bit (12-byte) IV for every encryption call; never hardcode or reuse IVs.
- ✓5. Store the IV and Authentication Tag alongside the ciphertext (they are not secrets, but integrity-critical).
8. In-Depth Technical Explanation
"If an application employs AES-GCM with a duplicated initialization vector, identical keystream sequences are generated for distinct plaintexts; the deterministic cryptographic causality is that XORing the resulting ciphertexts cancels the encryption key entirely, permitting algebraic plaintext recovery and authentication tag synthesis."
Underlying Root Cause Analysis
The security of modern symmetric encryption relies on nonces to ensure that encrypting identical plaintexts produces completely different ciphertexts every time. In Galois/Counter Mode (GCM), IV reuse is fatal because it transforms AES into a two-time pad: C1 ⊕ C2 = P1 ⊕ P2. In password hashing, the threat model is offline dictionary cracking where adversaries possess specialized hardware capable of billions of hashes per second. Only memory-hard algorithms force attackers to expend gigabytes of RAM per trial, making brute force economically infeasible.
Production Engineering Best Practices
- →Use AES-256-GCM or ChaCha20-Poly1305 (AEAD) rather than legacy unauthenticated modes like AES-CBC without HMAC.
- →Generate all cryptographic keys and IVs using `/dev/urandom` or `crypto.getRandomValues()`, never `Math.random()`.
- →Adopt OWASP password storage cheat sheet parameters: Argon2id with 64MB memory, 3 iterations, and 4 threads.
Common Pitfalls to Avoid
- ✕Assuming a "salt" makes SHA-256 secure against GPU brute-force attacks (it only defeats precomputed rainbow tables).
- ✕Concatenating plaintexts without length prefixing before hashing, causing hash-length extension issues.
- ✕Reusing an AES-GCM IV across multiple database records.
関連技術エコシステムと次の学習ステップ
関連技術解説記事
What Is Cryptographic Hashing?
Direct definition of one-way deterministic mathematical digest functions.
Hashing vs Encryption: Core Differences & Use Cases
Irreversible one-way digests compared to reversible confidentiality ciphers.
SHA-256 vs MD5: Cryptographic Security & Collision Comparison
Why MD5 is cryptographically broken and how SHA-256 prevents collision forgeries.
関連する技術Q&A
Why Does Changing One Character in an Input Completely Change the SHA-256 Hash?
Answer: Changing one character flips ~50% of all 256 output bits due to the cryptographic Avalanche Effect across 64 compression rounds.
Why Is MD5 Considered Cryptographically Broken?
Answer: MD5 is broken because practical chosen-prefix collision attacks can generate two distinct files with identical MD5 digests in seconds.
開発者向け規格・仕様リファレンス
次のステップへ進む
Cryptographic Hashing & Avalanche Lab
Explore the live avalanche effect and test SHA-256 bit distribution in real time.