Cryptographic Vulnerabilities

Protocol Downgrade Attacks

Force a connection to use a weaker, older protocol version.

Mitigation:
- Disable SSLv2, SSLv3, TLS 1.0, TLS 1.1 on all servers
- Enforce TLS 1.2+ (TLS 1.3 preferred)
- Disable export-grade and NULL cipher suites

nginx example:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5:!3DES;

Collision Attacks

Two different inputs produce the same hash output.

Hash functions vulnerable to collision:
- MD5: practical collision attacks (2004, Wang et al.)
- SHA-1: practical collision (2017, Google SHAttered attack)

SHA-1 Collision demo:
sha1sum shattered-1.pdf → 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
sha1sum shattered-2.pdf → 38762cf7f55934b34d179ae6a4c80cadccbb7f0a

Impact:
- Forge digital signatures
- Swap malicious file for signed legitimate file
- Break certificate uniqueness

Fix: Use SHA-256 or SHA-3 for all integrity-critical operations

Birthday Attack

Based on the birthday paradox — probability of finding two inputs with same hash is much higher than expected.

For an n-bit hash:
Expected collisions after ~2^(n/2) attempts (not 2^n)

MD5 (128-bit): ~2^64 operations → feasible
SHA-1 (160-bit): ~2^80 operations → feasible with GPU clusters
SHA-256 (256-bit): ~2^128 operations → not feasible

Rule: Hash output must be at least 2x the desired security level

Padding Oracle Attacks

Exploit error messages from decryption to decrypt ciphertext without the key.

Affects: CBC mode encryption
Example: POODLE, Lucky Thirteen, original ASP.NET padding oracle

How it works:
1. Attacker submits modified ciphertext
2. Server responds differently for valid vs. invalid padding
3. Attacker iterates → decrypts entire message block by block

Mitigations:
- Authenticated encryption (AES-GCM instead of AES-CBC)
- Constant-time padding validation (no timing leaks)
- Encrypt-then-MAC (not MAC-then-encrypt)

Weak or Broken Algorithms

ECB mode weakness — patterns visible in ciphertext:
          Plaintext          ECB Ciphertext
[BLOCK1][BLOCK1][BLOCK2] → [ENC1][ENC1][ENC2]  ← reveals duplicates

Fix: Always use CBC, CTR, or GCM mode

Key Management Vulnerabilities

Common mistakes:
- Hardcoded keys in source code
- Short key lengths (RSA < 2048, AES < 128)
- Reusing keys across different purposes/environments
- Never rotating keys
- Keys stored alongside encrypted data

Key length recommendations:
- AES: 128-bit minimum, 256-bit for sensitive data
- RSA: 2048-bit minimum, 3072+ for long-term security
- ECC: P-256 (128-bit security) minimum
- DH parameters: 2048-bit minimum

Timing Attacks

Measuring execution time to infer secrets.

Example: String comparison
if (token == expected):
  → "abc" vs "xyz" fails at position 0 (fast)
  → "abc" vs "abd" fails at position 2 (slightly slower)
  → Attacker measures time to enumerate correct characters

Fix: Constant-time comparison
Python: hmac.compare_digest(a, b)
Go:     subtle.ConstantTimeCompare(a, b)

Quantum Cryptography Threats

Post-quantum concern — future quantum computers could break current asymmetric crypto.

Vulnerable to quantum (Shor's algorithm):
- RSA (factoring)
- ECC (discrete logarithm)
- Diffie-Hellman

Safe against quantum:
- AES-256 (Grover's halves effective key size → 128-bit security remains)
- SHA-3 / SHA-512

NIST Post-Quantum Standards (finalized 2024):
- CRYSTALS-Kyber (key encapsulation)
- CRYSTALS-Dilithium (digital signatures)
- SPHINCS+ (signatures)

Certificate / PKI Vulnerabilities

Issues:
- Expired certificates
- Weak signature algorithms (MD5 or SHA-1 signed certs)
- Wildcard certificate over-use
- Self-signed certs in production (no trust verification)
- Rogue CA compromise (DigiNotar 2011 — Iranian MITM attacks)
- Certificate pinning bypass (mobile apps)

Mitigations:
- Certificate Transparency (CT) logs — detect misissued certs
- OCSP Stapling — real-time revocation checking
- Short-lived certificates (Let's Encrypt 90 days)
- HSTS + HPKP (with caution)