Intro to Cryptography

Cryptographic Attacks and Defense Strategies

Brute Force Attacks

A brute force attack represents the most straightforward assault on cryptographic systems. The attacker attempts every possible key combination until discovering the correct one. While conceptually simple, brute force efficacy depends entirely on key length and computational resources available.

Modern cryptographic standards specifically address brute force threats through key length requirements. A 128-bit symmetric key requires 2^128 possible combinations—approximately 340 undecillion attempts. Even with specialized quantum-accelerated hardware, brute force becomes computationally infeasible within human timescales. The security margin continues expanding as processors improve; longer keys scale exponentially rather than linearly with security gains.

Mitigation Strategies

• Key Length Standards: Use minimum 128-bit keys for symmetric encryption and 2048-bit for RSA. 256-bit symmetric and 4096-bit RSA offer substantially greater safety margins against emerging computational capabilities.
• Key Derivation Functions: Apply PBKDF2, bcrypt, or Argon2 when deriving keys from passwords. These functions intentionally increase computational cost, making brute force attacks exponentially more expensive.
• Rate Limiting: Implement authentication systems that throttle failed login attempts or temporarily lock accounts after repeated failures, preventing rapid-fire key guessing.
• Hardware Security Modules: Store master keys in HSMs that enforce strict rate limits on key operations and can tamper-detect unauthorized access attempts.

Dictionary and Lookup Table Attacks

Rather than computing brute force combinations in real time, attackers pre-compute hash values for dictionary words or common passwords, storing results in lookup tables (including rainbow tables). When a password hash is compromised, attackers simply search the table for a matching hash, bypassing the computational burden of brute force.

This attack became particularly dangerous following major database breaches where password hashes were exposed. Attack success rate depends on whether target passwords appear in dictionary word lists and whether the hashing mechanism includes cryptographic salt (random per-password values that prevent table reuse across systems).

Defense Implementation

• Cryptographic Salt: Generate unique random salt for each password (minimum 16 bytes). This ensures identical passwords produce different hashes across users and systems, rendering pre-computed tables useless.
• Computation Cost: Use adaptive hash functions (bcrypt, scrypt, Argon2) with configurable work factors. As hardware improves, increase work factors to maintain constant computational time for legitimate password verification.
• Password Policies: Enforce sufficient password entropy through length requirements and character variety. Move beyond simple rules to entropy-based checking or passphrase approaches.
• Breach Monitoring: Regularly check user emails against known breach databases. Proactively alert users when their credentials appear in compromised datasets, prompting password changes.

Cryptanalysis Attacks

Cryptanalysis represents sophisticated attacks targeting algorithmic weaknesses rather than brute forcing. Skilled cryptanalysts search for mathematical patterns, statistical biases, or computational shortcuts that reduce the effective security of encryption algorithms. Successful cryptanalysis can reduce a 256-bit key's security to equivalent 100-bit strength, catastrophically compromising systems.

Historical examples demonstrate cryptanalysis power: Enigma machine vulnerability exploitation shortened World War II; DES was theoretically broken decades before practical computational power existed; WEP wireless encryption fell to chosen-plaintext attacks exploiting IV reuse patterns. Modern standardized algorithms (AES, SHA-3) undergo years of public cryptanalysis before adoption, but emerging technologies remain vulnerable until thoroughly vetted.

Resistance Approaches

• Algorithm Selection: Use NIST-approved algorithms that have survived years of public cryptanalysis. Avoid proprietary or recently invented schemes without extensive peer review.
• Industry Standards: Prefer well-established protocols like TLS 1.3, NaCl/libsodium, or JOSE standards. These leverage community review and real-world attack feedback.
• Cryptographic Agility: Design systems to swap underlying algorithms without architectural changes. This enables rapid migration if cryptanalysis reveals weaknesses.
• Ongoing Monitoring: Subscribe to cryptography research summaries and security mailing lists. Track emerging attacks against your chosen algorithms and prepare upgrade paths.

Side-Channel Attacks

Side-channel attacks circumvent mathematical encryption strength by exploiting physical implementation properties. Rather than attacking the algorithm, attackers observe timing variation, power consumption, electromagnetic emissions, acoustic signatures, or other system behaviors during cryptographic operations. These channels leak information about secret keys without ever addressing the underlying mathematics.

Timing attacks exemplify the concept. Cryptographic libraries may complete key comparison operations in microsecond intervals that correlate with correct key bytes. Measuring thousands of comparison timings through network latency reveals which key bytes were correct before comparison completed. Similarly, power analysis measures current draw during cryptographic operations, revealing computational patterns that correlate with secret bits.

Mitigation Techniques

• Constant-Time Operations: Design cryptographic code to complete in fixed time regardless of input. Remove conditional branches that execute different paths based on secret data. Use masked operations that process all possibilities simultaneously.
• Power Isolation: Implement power supplies with noise filtering to prevent EMI leakage. Use differential power analysis (DPA) resistance techniques including random delays, instruction reordering, and data masking.
• Hardware Countermeasures: Deploy cryptographic operations on secure coprocessors or hardware security modules designed with physical tamper detection and power analysis shielding.
• Code Review and Testing: Conduct security audits specifically targeting side-channel vulnerabilities. Use dynamic analysis tools that detect variable execution paths based on secret inputs.

Man-in-the-Middle and Key Exchange Attacks

Even cryptographically sound algorithms fail if key exchange happens over insecure channels. Man-in-the-middle (MITM) attacks intercept communication, substituting the attacker's keys while impersonating both parties. The attacker then decrypts all traffic, reads or modifies messages, and re-encrypts for the recipient—all without either party detecting compromise.

MITM attacks succeed when key exchange lacks authentication. If Alice and Bob establish shared encryption keys but never verify each other's identity, an attacker can execute their own key exchange with each party, becoming the invisible middleman. This represents a fundamental cryptographic challenge: authentication must precede or accompany encryption.

Prevention Framework

• Authenticated Key Exchange: Use key exchange protocols like ECDHE with signature authentication (TLS 1.3). Verify public keys through certificate authorities or out-of-band mechanisms before encryption.
• Certificate Validation: Implement strict certificate chain validation including hostname verification, expiration checking, and revocation status (OCSP stapling). Never trust self-signed certificates in production.
• HPKP and DANE: Deploy HTTP Public Key Pinning (though deprecated) or DANE (DNS-based authentication of named entities) to cryptographically bind domain names to specific public keys.
• Network Security: Use VPNs, network access controls, and segmentation to prevent untrusted systems from intercepting traffic. Disable SSLv3, TLS 1.0, and 1.1 that remain vulnerable to MITM variants.

Implementation Vulnerabilities

The strongest cryptographic algorithm becomes worthless when implemented carelessly. Real-world systems fail through padding oracle vulnerabilities, IV reuse, improper random number generation, or algorithm misuse rather than mathematical breaks.

Notable failures include: WEP's 24-bit IV repeating after 16 million packets; Sony's PlayStation 3 hack exploiting identical random nonces; TLS implementations using insufficient randomness for nonces; OpenSSL's Heartbleed leaking 64KB of memory per request. Each represented implementation errors, not algorithmic weakness. Security-sensitive applications require specialized cryptography libraries maintaining constant-time implementations, peer-reviewed code, and rapid security patching.

Best Practices for Safe Implementation

• Proven Libraries: Use well-maintained cryptography libraries: NaCl/libsodium (high-level), OpenSSL/BoringSSL (production), or language-specific wrappers. Never implement cryptography from scratch.
• Correct Mode Selection: Use authenticated encryption modes like AES-GCM or ChaCha20-Poly1305. Avoid ECB mode (deterministic patterns visible) or CBC without authentication (vulnerable to tampering).
• Random Number Generation: Always use cryptographically secure RNG: /dev/urandom on Unix, CryptGenRandom on Windows, or language runtime crypto.getRandomValues(). Never seed with time or user input alone.
• Key Rotation: Implement automated key rotation policies. Aged keys are compromised keys. Regular rotation limits damage from potential future breaches.
• Security Audits: Engage professional cryptographic security auditors before production deployment. Have code reviewed specifically for implementation vulnerabilities, not just algorithm correctness.

Emerging Quantum Threats

Quantum computers threaten to catastrophically undermine current cryptographic security. Shor's algorithm can factor large numbers and compute discrete logarithms exponentially faster than classical algorithms, rendering RSA, ECDSA, and Diffie-Hellman obsolete within years of quantum computer maturation. An attacker with a sufficiently powerful quantum computer could retroactively decrypt archives of captured encrypted traffic.

The "harvest now, decrypt later" threat is particularly concerning. Adversaries are currently collecting and storing encrypted communications, betting that quantum computers will eventually decrypt them. This creates urgent migration timelines even for future threats. NIST has standardized post-quantum algorithms (ML-KEM, ML-DSA) transitioning to production deployment now to prevent cryptographic agility failures.

Quantum Resilience Strategy

• Algorithm Migration: Begin transitioning from RSA/ECDSA to NIST post-quantum standards. Hybrid approaches (using both classical and post-quantum algorithms) reduce deployment risk during transition periods.
• Cryptographic Agility: Design systems allowing algorithm swaps without infrastructure overhauls. This enables rapid pivot when new vulnerabilities emerge.
• Data Classification: Identify information requiring protection beyond 2040 (typical quantum threat timeline). Prioritize post-quantum migration for high-sensitivity data with decades-long confidentiality requirements.
• Quantum Key Distribution Research: Monitor QKD development for unhackable key exchange. While not universally deployable, QKD offers absolute mathematical guarantees against eavesdropping through quantum mechanics.

Security Incident Response

Despite comprehensive defenses, security incidents occur. Cryptographic systems must include detection and response mechanisms. Incident response for cryptographic breaches differs significantly from standard security incidents—compromised keys require immediate revocation, all encrypted data may become readable retroactively, and trust in communication channels evaporates.

Effective response includes: detecting compromise through anomaly monitoring (unusual access patterns, impossible travel); immediate key revocation and rotation; notifying affected parties within legal requirements; preserving forensic evidence for investigation; implementing emergency patches for root causes; and gradually rebuilding trust through certificate reissuance and re-authentication. Organizations should practice incident response scenarios regularly to ensure teams execute smoothly under pressure.