100% 브라우저 메모리 연산 • 서버 로그 수집 제로 • 즉각적인 실행
Curious Techie개발자 툴박스
Applied CryptographyIntermediate⏱️ 20 min challenge100% Client-Side

Applied Cryptography Lab: The Avalanche Effect, Symmetric AES-GCM vs RSA, and Key Derivation

Lab Objective

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.

Key Protocol Mechanics:
  • 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.
RFC Specifications:RFC 5116 (An Interface and Algorithms for Authenticated Encryption)RFC 9106 (Argon2 Password Hashing Function)

3. Hands-On Lab Instructions

1

Use the interactive Avalanche visualizer below: enter two strings differing by only 1 character (e.g., "Pass1" vs "Pass2").

2

Observe the 256-bit heatmap showing how ~128 bits flip completely across the two SHA-256 digests.

3

Benchmark how fast a GPU computes SHA-256 vs how Argon2id consumes memory and CPU iterations.

4

Encrypt a message using AES-256-GCM in the Web Crypto API workbench with a 96-bit cryptographically random IV.

5

Verify that altering any single byte of ciphertext causes AES-GCM decryption to throw an authentication tag mismatch error.

4. Interactive Lab Workbench

Interactive 256-Bit Avalanche & AES-GCM Workbench
Client-Side Simulation•Active

Modify input characters in real-time to watch SHA-256 output bits flip. Test AES-GCM authenticated encryption and tamper detection.

SHA-256 Digest A:
Computing...
SHA-256 Digest B:
Computing...
Avalanche Metric: Flipped Output Bits

Optimal cryptographic diffusion target is ~50% (128 of 256 bits).

Calculating...

5. Diagnostic Comprehension Questions

Q1

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.

Q2

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▼
In AES-GCM, the IV does not need to be kept secret, but it MUST be unique for every encryption call.
💡 Hint #2▼
Check the password hashing recommendation by OWASP: what algorithm is ranked #1?
💡 Hint #3▼
Remember that password hashing is a one-way function, whereas symmetric encryption is two-way (reversible with the key).

7. Verified Production Solution

Solution Summary

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.

TYPESCRIPT CONFIGURATION
// 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
  };
}
Remediation Steps:
  • ✓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

결정론적 기술 인과관계 (GEO)

"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.