Stage 2.2 — Cryptography Fundamentals

Encryption:
  Plaintext + Key + Algorithm → Ciphertext
  "Hello"  + "K"  + AES      → "x7Kp2mQ9..."

Decryption:
  Ciphertext + Key + Algorithm → Plaintext
  "x7Kp2mQ9..." + "K" + AES   → "Hello"

The algorithm (cipher) is typically PUBLIC — Kerckhoffs's principle:
  "A cryptosystem should be secure even if everything about the
   system, except the key, is public knowledge."

  Rationale: If security depends on algorithm secrecy ("security through
  obscurity"), once the algorithm is discovered (and it will be), all
  security is lost. Security must come from key secrecy alone.

  Corollary: Proprietary/secret encryption algorithms are a red flag.
  They haven't been publicly scrutinised — they are almost certainly weaker
  than publicly reviewed standards like AES.

Easy vs Hard Problems in Cryptography:

Symmetric (AES):
  Hard problem: Given ciphertext, find key without the key
  Security: Exhaustive search (brute force) of keyspace
  AES-128: 2^128 possible keys = 3.4 × 10^38 keys
  At 10^18 guesses/second: 1.07 × 10^13 years (longer than universe age)

Asymmetric (RSA):
  Hard problem: Integer Factorisation
  Given N = p × q (product of two large primes), find p and q
  Easy: multiply 2 large primes (milliseconds)
  Hard: factor the product (currently infeasible for 2048-bit)

Asymmetric (ECC):
  Hard problem: Elliptic Curve Discrete Logarithm Problem (ECDLP)
  Given P and Q = k×P (on an elliptic curve), find k
  Currently infeasible for 256-bit curves

  Key insight: 256-bit ECC ≈ 3072-bit RSA in security level
  ECC keys are much shorter for equivalent security

Hash Functions:
  Hard problem: Finding a collision or preimage
  Given H(x), find x (preimage resistance)
  Given H(x), find x' where H(x') = H(x) (second preimage)
  Find any x, x' where H(x) = H(x') (collision resistance)

NIST Recommended Key Sizes (2024):

Security Level  Symmetric  RSA/DH  ECC
──────────────────────────────────────────────────
80-bit          2TDEA       1024    160 (MINIMUM — deprecated)
112-bit         3TDEA       2048    224 (acceptable transitional)
128-bit         AES-128     3072    256 (recommended minimum)
192-bit         AES-192     7680    384
256-bit         AES-256    15360    521

"Security level" = approximate bits of work for best known attack

Future threat — Quantum Computing:
  Shor's algorithm breaks RSA and ECC entirely (exponential speedup)
  Grover's algorithm halves symmetric key security (128-bit → 64-bit effective)

  Post-Quantum Cryptography (PQC) — NIST finalists (2024):
  CRYSTALS-Kyber: Key encapsulation (replaces RSA/ECDH)
  CRYSTALS-Dilithium: Digital signatures (replaces RSA/ECDSA)
  FALCON: Digital signatures
  SPHINCS+: Hash-based signatures (no quantum threat to hash functions)

  Timeline: quantum computers capable of breaking RSA-2048 estimated 10-20 years
  Harvest now, decrypt later: attackers capturing encrypted traffic today
  to decrypt when quantum computers become available
  → "Cryptographically relevant quantum computer" (CRQC) threat

┌─────────────────┬──────────────────────────┬──────────────┬────────────────────┐
│                 │ Purpose                  │ Reversible?  │ Key Required?      │
├─────────────────┼──────────────────────────┼──────────────┼────────────────────┤
│ ENCODING        │ Format conversion        │ YES (trivial)│ NO                 │
│                 │ for transmission         │              │                    │
├─────────────────┼──────────────────────────┼──────────────┼────────────────────┤
│ ENCRYPTION      │ Confidentiality          │ YES (with key)│ YES               │
│                 │ (hide data from          │              │                    │
│                 │ unauthorised parties)    │              │                    │
├─────────────────┼──────────────────────────┼──────────────┼────────────────────┤
│ HASHING         │ Integrity verification   │ NO           │ NO                 │
│                 │ (one-way fingerprint)    │ (by design)  │                    │
└─────────────────┴──────────────────────────┴──────────────┴────────────────────┘

Common encodings:

Base64:
  Converts binary to printable ASCII
  Used: email attachments (MIME), HTTP Basic Auth, JWT tokens, data URIs
  "Hello" → "SGVsbG8="

  NOT encryption — security implication:
  "Authorization: Basic YWRtaW46cGFzc3dvcmQ=" in HTTP header
  Base64 decode → admin:password (instant)

URL Encoding (Percent Encoding):
  Converts special characters for URL safety
  "Hello World" → "Hello%20World"
  "/" → "%2F"

  Security: URL encoding bypass of WAFs/filters
  /etc/passwd → /%65%74%63/%70%61%73%73%77%64
  Some WAFs decode only once; double-encoded input bypasses them

ASCII/Unicode:
  Character ↔ number mapping
  'A' = 65 = 0x41
  No security provided

Hex encoding:
  Binary → hexadecimal representation
  0x48 0x65 0x6C 0x6C 0x6F = "Hello"

ROT13:
  Caesar cipher (rotate letters 13 positions)
  NOT encryption — symmetric but trivially reversed
  Used as "spoiler protection", never for security

# Encoding demonstrations:

# Base64 encode/decode:
echo "admin:password" | base64                    # Encode: YWRtaW46cGFzc3dvcmQ=
echo "YWRtaW46cGFzc3dvcmQ=" | base64 -d          # Decode: admin:password

# URL encode/decode with Python:
python3 -c "
import urllib.parse
# Encode
encoded = urllib.parse.quote('/etc/passwd')
print('Encoded:', encoded)   # %2Fetc%2Fpasswd

# Double encode (WAF bypass technique)
double = urllib.parse.quote(encoded)
print('Double:', double)    # %252Fetc%252Fpasswd
"

# Hex encode/decode:
echo "Hello" | xxd -p                              # Hex encode: 48656c6c6f0a
echo "48656c6c6f" | xxd -r -p                      # Hex decode: Hello

# Detect encoding in captured traffic:
echo "SGVsbG8gV29ybGQ=" | base64 -d               # Check if it's base64
echo "48656c6c6f" | python3 -c "import sys; print(bytes.fromhex(sys.stdin.read().strip()).decode())"

Most common security mistake: treating encoding as encryption

Example — "stored encoded" passwords (wrong!):
  Password: "SecretPass123"
  Stored as: base64("SecretPass123") = "U2VjcmV0UGFzczEyMw=="
  Security provided: ZERO
  If database is breached: echo "U2VjcmV0UGFzczEyMw==" | base64 -d → SecretPass123

Correct approach:
  Password: "SecretPass123"
  Stored as: bcrypt("SecretPass123") = "$2b$12$LKJSD...."
  Security: computationally infeasible to reverse
  If database is breached: hashes must be cracked (expensive)

Example — "encoded" API credentials in source code:
  API_KEY = base64.encode("ak_prod_12345secret")
  Developers think this hides the key in code
  Anyone who reads the code: decode → plaintext key
  Correct: environment variables, secrets management (Vault, AWS Secrets Manager)

Symmetric Encryption Flow:

  Alice                              Bob
    │                                 │
    │ Encrypt with shared key K       │
    │ "Hello" + K → "x7Kp2mQ9..."   │
    │                                 │
    │ ─── Ciphertext ───────────────→ │
    │     (safe to send publicly)     │
    │                                 │
    │                 Decrypt with K  │
    │                 "x7Kp2mQ9..." + K → "Hello"

Key distribution problem:
  How do Alice and Bob share key K securely?
  If they're communicating for the first time over an insecure channel:
  Sending K over the channel → attacker intercepts K → can decrypt everything

Solution: Use asymmetric encryption to exchange the symmetric key
  (this is exactly what TLS does — see Section 10)

Block Ciphers:
  Process data in fixed-size blocks (64-bit, 128-bit)
  Examples: AES (128-bit blocks), DES (64-bit blocks)
  Must handle data that isn't exactly block-size → padding
  Mode of operation determines security properties

Stream Ciphers:
  Process data one bit/byte at a time
  Examples: RC4 (broken), ChaCha20 (modern, secure)
  No padding needed
  More efficient for streaming data
  Crucial: NEVER reuse the same key+nonce combination
           Reuse → XOR ciphertexts → plaintext recovered

ECB (Electronic Codebook) — NEVER USE:
  Each block encrypted independently with same key
  Same plaintext block → same ciphertext block

  Security failure:
  Block 1: "Hello Wor" → "x7Kp2mQ9"
  Block 2: "Hello Wor" → "x7Kp2mQ9"  (IDENTICAL — reveals pattern)

  The Linux Penguin (ECB mode image encryption):
  Encrypt a bitmap image of a penguin with AES-ECB
  The outline of the penguin is still visible in the ciphertext
  Because identical pixel blocks produce identical ciphertext blocks
  ECB is broken for any data with patterns (text, images, structured data)

CBC (Cipher Block Chaining) — Common, requires care:
  Each block XOR'd with previous ciphertext before encryption
  Requires Initialization Vector (IV) for first block
  IV must be random and unique per message

  Vulnerabilities:
  - Padding oracle attacks (POODLE, CBC padding oracle)
  - IV reuse → information leakage
  - CBC decryption is parallelisable, encryption is not

CTR (Counter Mode) — Recommended:
  Uses block cipher as pseudo-random generator
  Counter value encrypted, XOR'd with plaintext
  Transforms block cipher into stream cipher
  Encryption AND decryption are parallelisable
  Random access within ciphertext possible

GCM (Galois/Counter Mode) — Best practice:
  CTR mode + Galois Message Authentication Code (GMAC)
  Provides both confidentiality AND integrity/authentication
  "Authenticated encryption with associated data" (AEAD)

  This is what TLS 1.3 uses: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305

  Critical: GCM nonce must NEVER be reused with the same key
  Nonce reuse in GCM → authentication key revealed → all security lost

AES Specifications:
  Block size: 128 bits (16 bytes) — ALWAYS
  Key sizes: 128, 192, or 256 bits
  Rounds: 10 (AES-128), 12 (AES-192), 14 (AES-256)

AES Internal Structure — Substitution-Permutation Network:

State: 4×4 matrix of bytes (128 bits)
┌──┬──┬──┬──┐
│b0│b4│b8│b12│
│b1│b5│b9│b13│
│b2│b6│b10│b14│
│b3│b7│b11│b15│
└──┴──┴──┴──┘

Each round (except last) applies four operations:

1. SubBytes: each byte replaced by substitute from S-box (256-entry lookup table)
   Provides non-linearity (without this, AES would be linear algebra — trivially broken)

2. ShiftRows: row i is shifted i bytes to the left
   Row 0: unchanged
   Row 1: [b1,b5,b9,b13] → [b5,b9,b13,b1]
   Row 2: [b2,b6,b10,b14] → [b10,b14,b2,b6]
   Row 3: [b3,b7,b11,b15] → [b15,b3,b7,b11]
   Provides diffusion across columns

3. MixColumns: each column multiplied by a matrix in GF(2^8)
   Provides diffusion — one input bit affects multiple output bytes

4. AddRoundKey: XOR state with round key (derived from original key via key schedule)

Final round: SubBytes + ShiftRows + AddRoundKey (no MixColumns)
Key schedule: original key expanded into 11 (AES-128) or 15 (AES-256) round keys

Security: No known attacks significantly better than brute force against AES itself
          All known vulnerabilities are implementation-level (timing attacks, cache attacks)

DES Specifications:
  Block size: 64 bits (8 bytes)
  Key size: 56 bits (actually 64 bits, 8 are parity bits)
  Rounds: 16 (Feistel network)

Why DES is broken:
  56-bit key = 2^56 = 72 quadrillion possible keys
  1998: EFF's "Deep Crack" machine cracked DES in 22 hours for $250,000
  2008: FPGA cluster cracked DES in 6.4 days for $10,000
  2012: Cloud computing: DES crackable in hours for ~$100
  Today: DES cracked in minutes on commodity hardware

DES Attacks:
  - Brute force: 2^56 key search (trivial with modern hardware)
  - Differential cryptanalysis: theoretical attacks requiring 2^47 chosen plaintexts
  - Linear cryptanalysis: requires 2^43 known plaintexts
  - Neither more practical than brute force — brute force is already practical

Do not use DES for any purpose.

3DES Variants:
  DES-EEE3: Encrypt-Encrypt-Encrypt with 3 different keys (168-bit key, 112-bit security)
  DES-EDE3: Encrypt-Decrypt-Encrypt with 3 different keys (most common, "Triple DES")
  DES-EDE2: Encrypt-Decrypt-Encrypt with 2 different keys (K1=K3, 112-bit key, 80-bit security)

Why 3DES doesn't give 168-bit security:
  Meet-in-the-Middle attack reduces DES-EDE3 to ~112 bits of security
  Still exponentially better than single DES

Problems with 3DES:
  - 64-bit block size → "birthday bound" problem
  - After 2^32 blocks (~32 GB), collisions become likely
  - SWEET32 attack (CVE-2016-2183): exploits 64-bit block birthday bound
    to recover plaintext from long-lived TLS sessions using 3DES
  - Only ~112 bits of security (not 168)
  - MUCH slower than AES (3× DES operations per block)

NIST deprecated 3DES in 2017 (allowed until 2023, disallowed after)
3DES is still found in: legacy payment systems (PCI-DSS grace period),
old TLS configurations, mainframe systems

Blowfish (Bruce Schneier, 1993):
  Block size: 64 bits (same birthday-bound problem as DES/3DES)
  Key size: 32-448 bits (variable)
  Design: public domain, no patent

  Security: No known significant vulnerabilities against Blowfish itself
  Problem: 64-bit block size (SWEET32 applies)
  Use: bcrypt password hashing algorithm uses modified Blowfish (Eksblowfish)
       bcrypt is still recommended for passwords — Blowfish-derived, not raw Blowfish

  Do not use raw Blowfish for data encryption today.

Twofish (Schneier et al., 1998):
  AES finalist (lost to Rijndael in 2001 selection)
  Block size: 128 bits (no birthday-bound problem)
  Key size: 128, 192, 256 bits
  Public domain, no patent
  Still considered secure — no known practical attacks
  Less deployed than AES (lost the competition)
  Available in: TrueCrypt/VeraCrypt, GPG, some TLS configurations

# Symmetric encryption in practice:

# AES-256-GCM encryption with OpenSSL:
openssl enc -aes-256-gcm \
    -in plaintext.txt \
    -out encrypted.bin \
    -pass pass:"MySecretPassword" \
    -pbkdf2 \
    -iter 100000
# -aes-256-gcm: AES 256-bit in GCM mode (authenticated encryption)
# -pass pass: derive key from password
# -pbkdf2: use PBKDF2 key derivation (not simple MD5)
# -iter 100000: 100,000 iterations of PBKDF2 (makes brute force slower)

# Decryption:
openssl enc -d -aes-256-gcm \
    -in encrypted.bin \
    -out decrypted.txt \
    -pass pass:"MySecretPassword" \
    -pbkdf2 \
    -iter 100000

# AES in Python (cryptography library):
python3 << 'EOF'
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# Generate random 256-bit key
key = os.urandom(32)              # 32 bytes = 256 bits

# Generate random 96-bit nonce (12 bytes — recommended for GCM)
nonce = os.urandom(12)

# Create AES-GCM cipher
aesgcm = AESGCM(key)

# Encrypt
plaintext = b"Secret message"
associated_data = b"authenticated but not encrypted metadata"
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)
print(f"Ciphertext: {ciphertext.hex()}")
print(f"Length: {len(ciphertext)} bytes (plaintext + 16-byte auth tag)")

# Decrypt (will raise exception if tampered)
try:
    decrypted = aesgcm.decrypt(nonce, ciphertext, associated_data)
    print(f"Decrypted: {decrypted}")
except Exception as e:
    print(f"Authentication failed: {e}")  # Ciphertext was modified
EOF

# Check what cipher a TLS connection uses:
openssl s_client -connect google.com:443 2>/dev/null | grep "Cipher"
# Look for: AES-128-GCM or AES-256-GCM or CHACHA20-POLY1305

# Test if a server still supports broken ciphers:
nmap --script ssl-enum-ciphers -p 443 target.com | grep -E "DES|RC4|NULL|EXPORT"
# Any of these: immediately report — broken ciphers in use

Key Pair Relationship:

  Private Key                Public Key
  ───────────               ─────────────
  Secret (never share)      Share freely
  Decrypts what public      Encrypts for private
  key encrypted             key holder
  Signs messages            Verifies signature

The magic: public and private keys are mathematically related
but it is computationally infeasible to derive the private key
from the public key (assuming the hard problems hold)

Analogy:
  Public key = padlock (anyone can lock)
  Private key = key to open the padlock

  You give your padlock to Alice
  Alice puts message in box, locks with your padlock
  Only you (private key holder) can open the padlock

RSA Key Generation:
1. Choose two large prime numbers p and q (each ~1024-2048 bits)
2. Compute n = p × q (the modulus — public)
3. Compute φ(n) = (p-1)(q-1) (Euler's totient — secret)
4. Choose e such that 1 < e < φ(n) and gcd(e, φ(n)) = 1
   (public exponent — usually 65537 = 2^16 + 1)
5. Compute d = e^(-1) mod φ(n) (private exponent)

Public key:  (n, e)
Private key: (n, d)  [also need p, q for efficient computation]

RSA Encryption (message M):
  Ciphertext C = M^e mod n

RSA Decryption:
  Message M = C^d mod n

Security: Given n, find p and q (integer factorisation)
  This is computationally hard for large n (2048+ bits)

RSA Key Sizes and Security:
  1024-bit: BROKEN (factorable since 2010, do not use)
  2048-bit: Currently secure minimum (recommended for legacy compat)
  3072-bit: Post-2030 recommendation
  4096-bit: High-security applications

RSA-768 factored (2009): 768-bit RSA key factored using 30 years of CPU time
RSA-1024: Not yet factored but academic consensus: should not be used
ROCA vulnerability (CVE-2017-15361):
  Infineon Technologies RSA key generation library flaw
  Generated keys with detectable prime patterns
  Allowed factoring 1024-bit keys in <1 hour, 2048-bit in ~2 weeks
  Affected: YubiKey, TPM chips, smart cards
  1.25 billion keys potentially vulnerable

Bleichenbacher's attack (1998, recurring as ROBOT 2017):
  RSA PKCS#1 v1.5 padding oracle
  If server responds differently to valid vs invalid padding:
  Attacker can recover plaintext of RSA-encrypted messages
  Requires ~1 million queries to server
  Affected F5, Citrix, Cisco, Palo Alto and others in 2017
  ROBOT (Return Of Bleichenbacher's Oracle Threat) - 19 years after original

Elliptic Curve:
  y² = x³ + ax + b (over a finite field GF(p))

  Standard curves (NIST):
  P-256 (secp256r1): 256-bit, 128-bit security
  P-384 (secp384r1): 384-bit, 192-bit security
  P-521 (secp521r1): 521-bit, 260-bit security

  Alternative curves (more trusted implementation properties):
  Curve25519: Ed25519 signatures, X25519 key exchange (preferred)
              Designed by Daniel Bernstein, no NIST involvement
              No concerns about NIST/NSA backdoor in curve parameters
              Used in: Signal, TLS 1.3 key exchange, SSH keys, WireGuard

ECC Key Exchange (ECDH — Elliptic Curve Diffie-Hellman):
  1. Alice generates private key a, computes public key A = a×G (G = generator point)
  2. Bob generates private key b, computes public key B = b×G
  3. Alice computes shared secret: S = a×B = a×(b×G) = (ab)×G
  4. Bob computes shared secret: S = b×A = b×(a×G) = (ab)×G
  Both get the same shared secret without ever transmitting it

ECC Signatures (ECDSA — Elliptic Curve Digital Signature Algorithm):
  Sign with private key, verify with public key
  Much shorter signatures than RSA for equivalent security:
  RSA-2048 signature: 256 bytes
  ECDSA-256 signature: 64 bytes

Advantage over RSA:
  256-bit ECC ≈ 3072-bit RSA in security
  Shorter keys = faster computation, less storage, smaller certificates
  TLS 1.3 exclusively uses ECDHE for key exchange (no RSA key exchange)

Classic DH (finite field):

1. Public parameters: prime p, generator g (both public, known to everyone)

2. Alice: chooses secret a, computes A = g^a mod p (sends A to Bob)
3. Bob:   chooses secret b, computes B = g^b mod p (sends B to Alice)

4. Alice: computes S = B^a mod p = (g^b)^a mod p = g^(ab) mod p
5. Bob:   computes S = A^b mod p = (g^a)^b mod p = g^(ab) mod p

Both get the same S = g^(ab) mod p — the shared secret
Attacker sees: p, g, A=g^a mod p, B=g^b mod p
To find S: must solve discrete logarithm problem (find a from g^a mod p)
This is computationally hard for large p

DH Key Sizes:
  1024-bit: deprecated (Logjam attack showed feasibility of precomputation)
  2048-bit: minimum acceptable
  3072-bit: recommended

Ephemeral DH (DHE / ECDHE):
  New a, b generated for each session
  Provides: Perfect Forward Secrecy (PFS)
  If long-term key (private key) is compromised later:
  Past sessions cannot be decrypted (each had unique ephemeral keys)

  CRITICAL SECURITY PROPERTY:
  RSA key exchange (static): compromise private key → decrypt ALL past sessions
  ECDHE: compromise private key → can impersonate server, but past sessions safe

  TLS 1.3 mandates ECDHE — forward secrecy is no longer optional

# Asymmetric cryptography in practice:

# Generate RSA key pair:
openssl genrsa -out private.pem 4096           # Generate 4096-bit RSA private key
openssl rsa -in private.pem -pubout -out public.pem  # Extract public key

# View key details:
openssl rsa -in private.pem -text -noout | head -20
# Shows: modulus, public exponent (65537), private exponent, primes

# Generate ECC key pair (preferred):
openssl ecparam -name prime256v1 -genkey -noout -out ec_private.pem  # P-256
openssl ec -in ec_private.pem -pubout -out ec_public.pem
# Or use Curve25519 (preferred):
openssl genpkey -algorithm X25519 -out x25519_private.pem
openssl pkey -in x25519_private.pem -pubout -out x25519_public.pem

# RSA encrypt/decrypt:
echo "Secret message" > plaintext.txt
openssl rsautl -encrypt -inkey public.pem -pubin -in plaintext.txt -out encrypted.bin
openssl rsautl -decrypt -inkey private.pem -in encrypted.bin -out decrypted.txt
cat decrypted.txt

# Check a server's public key:
openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Public Key Algorithm|Public-Key:"
# Shows: RSA 2048-bit or EC P-256 etc.

# Python - RSA encryption:
python3 << 'EOF'
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization

# Generate 2048-bit RSA key pair
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()

# Encrypt with public key (OAEP padding — correct padding scheme)
message = b"Secret message"
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
print(f"Encrypted: {ciphertext[:20].hex()}... ({len(ciphertext)} bytes)")

# Decrypt with private key
plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()),
                 algorithm=hashes.SHA256(), label=None)
)
print(f"Decrypted: {plaintext}")
EOF

Hash Function Properties (required for security):

1. Deterministic: Same input → always same output
   hash("Hello") → always produces the same hash

2. Fixed Output Size: Regardless of input length
   hash("a") → 256 bits
   hash(entire_movie.mp4) → 256 bits (same length)

3. One-Way (Preimage Resistance):
   Given H, computationally infeasible to find M where hash(M) = H
   Cannot reverse the hash to get input

4. Second Preimage Resistance:
   Given M1, computationally infeasible to find M2 where hash(M1) = hash(M2)
   Cannot find a different input with the same hash

5. Collision Resistance:
   Computationally infeasible to find ANY M1, M2 where hash(M1) = hash(M2)
   (Note: collisions MUST exist — infinite inputs, finite outputs)
   But finding them should be computationally infeasible

6. Avalanche Effect: Small change → completely different output
   hash("Hello") → "2cf24d..."
   hash("hello") → "b94d27b9..."  (completely different — 1 bit change)
   This prevents any correlation between input and output

Algorithm  Output   Status         Best Attack           Security
──────────────────────────────────────────────────────────────────────────────
MD5        128-bit  BROKEN         Collision: 2009       NONE for integrity
                                   (Flame malware used   DO NOT USE
                                   MD5 collision for
                                   code signing bypass)
SHA-1      160-bit  BROKEN         SHAttered (2017):     DO NOT USE
                                   Google/CWI computed   for security
                                   first SHA-1 collision purposes
                                   Cost: ~$100,000 GPU
SHA-224    224-bit  Deprecated     Theoretical only      Acceptable transitional
SHA-256    256-bit  SECURE         No practical attack    128-bit security
                                   known                  USE THIS
SHA-384    384-bit  SECURE         No practical attack    192-bit security
SHA-512    512-bit  SECURE         No practical attack    256-bit security
SHA-3-256  256-bit  SECURE         Different design       128-bit security
                                   from SHA-2 family     Use for diversity
BLAKE2b    512-bit  SECURE         No practical attack    256-bit security
                                                          Faster than SHA-3
BLAKE3     256-bit  SECURE         No practical attack    128-bit security
                                                          Fastest modern hash

MD5 (Ronald Rivest, 1992):
  Output: 128-bit (32 hex characters)

Timeline of MD5's death:
  1993: Den Boer and Bosselaers: theoretical weaknesses found
  1996: Dobbertin: MD5 compression function collisions found (partial break)
  2004: Wang et al.: first full MD5 collisions computed
         Cost: hours on a laptop
  2005: Lenstra et al.: demonstrated MD5-based X.509 certificate collision
         Two different certificates with the same MD5 hash
  2008: CMU/Sotirov: rogue CA certificate using MD5 collision
         Created fraudulent intermediate CA certificate trusted by all browsers
         Full HTTPS impersonation of any website theoretically possible
  2012: Flame malware: used MD5 collision to forge Microsoft code-signing certificate
         Malware appeared to be legitimately signed by Microsoft
         Affected: Iranian nuclear programme (likely)

MD5 in security today:
  NEVER use for: passwords, digital signatures, certificates, any security purpose
  MAY use for: non-security file deduplication, non-security checksums
               (but SHA-256 is equally fast and secure — just use SHA-256)
  Found in: legacy systems, old configurations, some OT firmware update checks

SHA-1 (NIST, 1995):
  Output: 160-bit (40 hex characters)

Timeline:
  2005: Xiaoyun Wang: theoretical collision attack (2^69 operations vs 2^80 ideal)
  2007: NIST recommends migration away from SHA-1
  2011: CA/Browser Forum: ban SHA-1 certificates after 2015
  2017: SHAttered attack (Google/CWI Amsterdam):
         First SHA-1 collision computed
         Two different PDF files with IDENTICAL SHA-1 hashes
         Cost: 9 quintillion SHA-1 computations = ~$100,000 in cloud computing
         Same PDF files have different content but same SHA-1 hash

  2020: Chosen-prefix collision: find collision given arbitrary prefixes
         More powerful than identical-prefix collision
         Cost reduced to ~$50,000

Impact of SHAttered:
  Git uses SHA-1 internally (aware, mitigations added: SHA-256 migration ongoing)
  Any SHA-1-based integrity check can potentially be bypassed

SHA-1 in security today:
  NEVER use for: digital signatures, certificates, TLS, code signing
  Legacy OT concern: many industrial firmware update mechanisms use SHA-1
                     for integrity verification — still vulnerable to SHAttered
                     type attacks on controlled devices

SHA-256 (NIST, 2001) — Part of SHA-2 family:
  Output: 256-bit (64 hex characters)
  Internal structure: Merkle-Damgård construction with Davies-Meyer compression
  No practical attacks known
  Used in: Bitcoin, TLS, code signing, most modern security applications

SHA-3 (Keccak, NIST standardised 2015):
  Different internal structure from SHA-2 (sponge construction)
  Not vulnerable to length extension attacks (SHA-2 is)
  SHA-3-256 output: 256-bit
  Adoption: slower (SHA-2 still dominant)
  Use case: when diversity from SHA-2 is needed (defence against future SHA-2 attacks)

Length Extension Attack (SHA-2 weakness, not SHA-3):
  Given H(m) and len(m) but NOT m:
  Attacker can compute H(m || padding || extension) without knowing m

  Attack scenario:
  API: sign request with SHA-256(secret_key || request_params)
  Attacker: knows H(secret_key || "user=alice")
            Can compute H(secret_key || "user=alice" || padding || "&admin=true")
            Without knowing secret_key!

  Fix: use HMAC instead of raw hash for message authentication
  HMAC is not vulnerable to length extension attacks

# Hash function demonstrations:

# Calculate hashes of same file:
echo "Hello World" > test.txt
md5sum test.txt         # MD5: e59ff97941044f85df5297e1c302d260
sha1sum test.txt        # SHA1: 648a6a6ffffdaa0badb23b8baf90b6168dd16b3a
sha256sum test.txt      # SHA256: d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26
sha512sum test.txt      # SHA512: (128 hex chars)
b2sum test.txt          # BLAKE2b (package: b2sum)

# Verify file integrity (download verification):
wget https://example.com/software.tar.gz
wget https://example.com/software.tar.gz.sha256sum
sha256sum -c software.tar.gz.sha256sum
# "software.tar.gz: OK" = file not tampered

# Demonstrate avalanche effect:
python3 << 'EOF'
import hashlib

msg1 = b"Hello World"
msg2 = b"Hello world"  # Only capital W changed

h1 = hashlib.sha256(msg1).hexdigest()
h2 = hashlib.sha256(msg2).hexdigest()

print(f"SHA-256('Hello World'): {h1}")
print(f"SHA-256('Hello world'): {h2}")

# Count differing bits:
b1 = int(h1, 16)
b2 = int(h2, 16)
diff = bin(b1 ^ b2).count('1')
print(f"Differing bits: {diff} out of 256 ({diff/256*100:.1f}%)")
# Approximately 128 bits differ (50%) — avalanche effect
EOF

# Demonstrate MD5 collision (SHAttered file pair):
# Download the two PDF files that have same SHA-1:
# wget https://shattered.io/static/shattered-1.pdf
# wget https://shattered.io/static/shattered-2.pdf
# sha1sum shattered-1.pdf shattered-2.pdf  # IDENTICAL SHA-1
# sha256sum shattered-1.pdf shattered-2.pdf  # DIFFERENT SHA-256

# HMAC (keyed hash, MAC):
python3 -c "
import hmac, hashlib
key = b'secret_key'
message = b'user=alice&action=transfer&amount=1000'
mac = hmac.new(key, message, hashlib.sha256).hexdigest()
print(f'HMAC-SHA256: {mac}')
# Attacker cannot forge this without knowing the key
# Not vulnerable to length extension attacks
"

Attack 1 — Rainbow Tables:
  Precompute hashes of millions of common passwords:
  MD5("password")  = "5f4dcc3b5aa765d61d8327deb882cf99"
  MD5("123456")    = "e10adc3949ba59abbe56e057f20f883e"
  MD5("admin")     = "21232f297a57a5a743894a0e4a801fc3"

  Breach database → look up hash in precomputed table → plaintext in milliseconds
  No computation needed — just lookup

  Countermeasure: Salt (makes precomputation impossible)

Attack 2 — Dictionary Attack:
  Hash common passwords and compare to stolen hashes
  For each candidate password: compute hash → compare
  GPU can compute billions of SHA-256 hashes per second

  Countermeasure: Slow hash functions (bcrypt, scrypt, Argon2)

WITHOUT SALT:
  User A: password "letmein" → SHA-256 → "b3fba..."
  User B: password "letmein" → SHA-256 → "b3fba..."

  Same password → same hash
  Attacker sees: User A and B have same hash → same password
  Crack one → crack both
  Rainbow table works: "b3fba..." → "letmein"

WITH SALT:
  User A: password "letmein" + salt "xK7mP2" → SHA-256 → "a1b2c3..."
  User B: password "letmein" + salt "9qRnL5" → SHA-256 → "z9y8x7..."

  Same password → DIFFERENT hashes (different salts)
  Attacker must crack each hash independently
  Rainbow tables are useless (different salt = different table needed per user)

  Salt must be:
  - Random (generated with CSPRNG)
  - Unique per password (even same user resetting password gets new salt)
  - Stored alongside the hash (not secret — attacker who gets DB gets salt too)
    But that's OK — salt defeats rainbow tables even when known
  - Long enough: 16+ bytes (128+ bits)

bcrypt (Blowfish-based, 1999):
  Incorporates salt automatically
  Output format: $2b$12$SALT22CHARS.HASH31CHARS
    $2b$ = bcrypt version
    12   = cost factor (2^12 rounds = 4096 iterations)
    next 22 chars = salt (128 bits)
    last 31 chars = hash

  Cost factor: controls speed (and therefore brute-force resistance)
  Higher cost = slower hash = more resistant to brute force
  Recommendation: choose cost factor so hashing takes 100-300ms
  Increase cost factor over time as hardware gets faster

Argon2 (Password Hashing Competition winner, 2015):
  Three variants:
  Argon2d: data-dependent, resists GPU cracking
  Argon2i: data-independent, resists side-channel attacks
  Argon2id: hybrid, RECOMMENDED for passwords

  Parameters: time cost, memory cost, parallelism
  Memory cost: makes hardware attacks (ASIC/GPU) expensive
  Argon2id(time=3, memory=64MB, parallel=4) recommended by OWASP (2024)

WITH SALT + PEPPER:
  password + salt + pepper → hash

  Storage:
  Database: salt + hash (attacker who breaches DB gets these)
  Application/HSM: pepper (attacker who only breaches DB doesn't have this)

  Even with: stolen database + knowing salt + knowing algorithm
  Attacker cannot crack without pepper
  Must also breach application server or HSM

  Pepper requirements:
  - HIGH entropy (256 bits random)
  - Different from the salt
  - Stored separately from the database (application config, HSM)
  - Never logged or exposed in error messages
  - Rotate with re-hashing (requires all users to re-authenticate)

Limitations:
  If attacker compromises BOTH database AND application server: both salt and pepper available
  Pepper is only effective if the attacker has access to ONE but not both

Combined: salt + pepper + slow hash (Argon2id or bcrypt) is the current gold standard

# Password hashing in practice:

# bcrypt in Python:
python3 << 'EOF'
import bcrypt
import time

password = b"UserPassword123!"
pepper = b"AppSecretPepper256BitRandom"  # Store in app config, not DB

# Hash (bcrypt handles salt automatically)
peppered = password + pepper
start = time.time()
hashed = bcrypt.hashpw(peppered, bcrypt.gensalt(rounds=12))
elapsed = time.time() - start
print(f"bcrypt hash: {hashed.decode()}")
print(f"Time to hash: {elapsed:.3f}s (should be ~100-300ms)")

# Verify:
is_valid = bcrypt.checkpw(peppered, hashed)
print(f"Password valid: {is_valid}")

# Wrong password:
wrong = b"WrongPassword" + pepper
is_valid = bcrypt.checkpw(wrong, hashed)
print(f"Wrong password valid: {is_valid}")  # False
EOF

# Argon2id in Python:
python3 << 'EOF'
from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

# OWASP recommended parameters
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4, hash_len=32, salt_len=16)
# time_cost=3: 3 iterations
# memory_cost=65536: 64MB RAM (makes GPU/ASIC attacks expensive)
# parallelism=4: use 4 threads

password = "UserPassword123!"
pepper = "AppSecretPepper"

hash_val = ph.hash(password + pepper)
print(f"Argon2id hash: {hash_val[:50]}...")

# Verify:
try:
    ph.verify(hash_val, password + pepper)
    print("Password valid")
except VerifyMismatchError:
    print("Password invalid")
EOF

# Check what hash algorithm is used in /etc/shadow:
sudo cat /etc/shadow | head -3 | cut -d: -f2 | cut -c1-5
# $6$ = SHA-512 (acceptable for system use)
# $5$ = SHA-256
# $y$ = yescrypt (best, modern Linux default)
# $2b$ = bcrypt
# Blank or no $ = no password (check immediately!)

# Crack example hashes to understand speed difference:
# hashcat -m 0 hash.txt wordlist.txt        # MD5: billions/sec
# hashcat -m 3200 hash.txt wordlist.txt     # bcrypt: thousands/sec
# hashcat -m 1800 hash.txt wordlist.txt     # SHA-512crypt: millions/sec
# Speed difference: MD5 = 1,000,000× faster than bcrypt
# This is exactly why bcrypt for passwords matters

Digital Signature Process:

SIGNING (sender with private key):
  Message M → Hash(M) → Sign with Private Key → Signature S
  Send: (M, S)

VERIFICATION (receiver with public key):
  Receive: (M, S)
  Compute: Hash(M) → H1
  Decrypt: S with Public Key → H2
  Verify:  H1 == H2?
    YES: signature valid (M not tampered, came from key holder)
    NO:  signature invalid (M modified, or wrong signer)

Why hash first?
  RSA can only sign data ≤ key size (2048 bits)
  Hash reduces any-size message to fixed output (256 bits for SHA-256)
  Sign the hash, not the message

  RSA-PSS (Probabilistic Signature Scheme) — correct:
  Uses random salt, provably secure, RECOMMENDED

  RSA-PKCS1v15 — legacy:
  Deterministic, older vulnerabilities, still widely used but avoid for new systems

  ECDSA (Elliptic Curve Digital Signature Algorithm):
  Based on ECC discrete log problem
  256-bit signature (much shorter than RSA-2048's 256-byte signature)
  Requires cryptographically random k value per signature

  Critical ECDSA vulnerability: k reuse
  If same k used twice with different messages:
  Private key can be recovered algebraically

  2010: PlayStation 3 used constant k in ECDSA → private key recovered
  2013: Android Bitcoin wallet ECDSA k reuse → keys stolen

Code Signing: applying digital signatures to software to verify authenticity

Windows Authenticode:
  Developer signs executable with private key (from certificate authority)
  Windows verifies signature before execution (if policy enforced)
  "Published by: Microsoft Corporation" with valid chain → trusted
  Self-signed → warning
  No signature → warning or block

  Attack: steal code signing certificate and private key
  Example: Stuxnet used stolen certificates from Realtek and JMicron
           to sign kernel drivers → bypassed Windows driver signing requirement

Linux Package Signing:
  Debian/Ubuntu: GPG signatures on packages + repository metadata
  RPM: GPG signatures on packages
  apt: verifies package signatures automatically

  Verify GPG signature:
  gpg --verify file.sig file

Certificate Transparency (CT):
  All publicly trusted TLS certificates must be logged to CT logs
  Allows monitoring for unexpected certificates for your domains
  Tools: crt.sh, certspotter, Google CT

SSH Host Key Verification:
  SSH server presents public key fingerprint
  Client verifies against known_hosts
  First connection: TOFU (Trust On First Use) — user must verify

# Digital signatures in practice:

# Sign a file with private key:
openssl dgst -sha256 -sign private.pem -out signature.bin document.txt

# Verify signature:
openssl dgst -sha256 -verify public.pem -signature signature.bin document.txt
# "Verified OK" = authentic and unmodified

# Sign with GPG:
gpg --gen-key                                    # Generate GPG key pair
gpg --sign --armor document.txt                  # Sign (creates document.txt.asc)
gpg --verify document.txt.asc document.txt       # Verify signature

# Python - sign and verify:
python3 << 'EOF'
from cryptography.hazmat.primitives.asymmetric import ec, utils
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.exceptions import InvalidSignature

# Generate EC key pair (P-256)
private_key = ec.generate_private_key(ec.SECP256R1())
public_key = private_key.public_key()

# Sign message
message = b"This document is authentic"
signature = private_key.sign(message, ec.ECDSA(hashes.SHA256()))
print(f"Signature: {signature.hex()[:40]}... ({len(signature)} bytes)")

# Verify - original message:
try:
    public_key.verify(signature, message, ec.ECDSA(hashes.SHA256()))
    print("Signature VALID")
except InvalidSignature:
    print("Signature INVALID")

# Verify - tampered message:
tampered = b"This document is authentic and has extra admin=true"
try:
    public_key.verify(signature, tampered, ec.ECDSA(hashes.SHA256()))
    print("Tampered signature VALID")  # Should never reach here
except InvalidSignature:
    print("Tampered message: Signature INVALID — tampering detected!")
EOF

# Check certificate signature:
openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -text | grep -A3 "Signature Algorithm"

The Man-in-the-Middle Problem:

Without PKI:
  Alice wants to connect to "bank.com"
  Attacker intercepts connection:
  Alice ←→ Attacker ←→ Bank
  Attacker sends own public key to Alice, claiming to be Bank
  Alice encrypts with attacker's key
  Attacker decrypts, re-encrypts with bank's real key
  Alice has no way to know she's talking to the attacker

With PKI:
  Bank has a certificate signed by a trusted Certificate Authority (CA)
  Certificate contains: Bank's public key + domain name + CA signature
  Alice's browser trusts the CA (comes pre-installed)
  Browser verifies: CA signature is valid → this public key belongs to bank.com
  Attacker cannot forge this — doesn't have CA's private key

X.509 Certificate Fields:

Version:             3 (v3 is current)
Serial Number:       Unique identifier assigned by CA
Signature Algorithm: sha256WithRSAEncryption or ecdsa-with-SHA256
Issuer:              CA that signed this certificate
                     CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
Validity:
  Not Before:        2024-01-01 00:00:00 UTC
  Not After:         2025-01-31 23:59:59 UTC
Subject:             Who this certificate belongs to
                     CN=*.google.com, O=Google LLC, C=US
Subject Public Key:  The actual public key (RSA or EC)
                     RSA 2048-bit or ECC P-256
Extensions:
  Subject Alternative Names (SANs): All domains covered
    DNS:*.google.com
    DNS:google.com
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usage: TLS Web Server Authentication
  Certificate Policies: https://pki.goog/repository/
  CRL Distribution Points: URL to check if certificate is revoked
  OCSP: URL for real-time revocation checking
  Certificate Transparency: SCT list (proof of CT log inclusion)
Signature: CA's signature over all of the above

PKI Trust Hierarchy:

Root CA (self-signed, highest trust)
  └── Intermediate CA (signed by Root CA)
        └── End-Entity Certificate (signed by Intermediate CA)
            (the certificate for google.com, for example)

Root CA:
  Stored in OS/browser trust stores (pre-installed)
  ~150 trusted root CAs in major browsers
  Private key extremely protected (offline, HSM, physical vault)
  Very rarely used directly (too valuable to risk)

Intermediate CA:
  Signed by root CA, issues end-entity certificates
  Private key stored in HSM (Hardware Security Module)
  If compromised: can be revoked without compromising root

End-Entity Certificate:
  Issued to the specific organisation/domain
  Short-lived (1 year max since 2020 for public TLS)

Chain validation:
  Browser validates end-entity cert is signed by intermediate CA
  Validates intermediate CA is signed by root CA
  Validates root CA is in trusted store
  Validates none are expired or revoked
  Validates domain name matches (SAN check)

What if a private key is compromised? Certificate must be revoked.

CRL (Certificate Revocation List):
  List of revoked serial numbers, signed by CA, published periodically
  Browsers download CRL and check if certificate serial number is in it
  Problem: CRL can be large, infrequent updates, check often skipped

OCSP (Online Certificate Status Protocol):
  Real-time revocation check — query CA's OCSP responder per certificate
  Faster than CRL, smaller response
  Problem: Privacy (CA knows which sites you visit), performance, failure mode

OCSP Stapling:
  Server periodically fetches its own OCSP response from CA
  Includes ("staples") the response in TLS handshake
  Browser gets revocation status without contacting CA
  Best approach: solves privacy and performance

Revocation in practice (sadly):
  Browser failure to get CRL/OCSP response → typically ALLOW connection
  "Soft fail" = revocation checking provides minimal real protection
  Exception: Certificate Pinning — browser refuses connection if pin mismatch

CAA DNS Records:
  DNS record specifying which CAs may issue certificates for your domain
  example.com CAA 0 issue "letsencrypt.org"
  Prevents misissued certificates from unauthorised CAs
  Check: dig CAA yourdomain.com

# PKI and certificate analysis:

# View a server's full certificate chain:
openssl s_client -connect google.com:443 -showcerts 2>/dev/null | \
    grep -E "BEGIN|END|subject|issuer|Not"

# Check certificate details:
openssl s_client -connect google.com:443 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not After|DNS:"

# Verify certificate chain:
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt certificate.pem

# Check OCSP status:
openssl s_client -connect google.com:443 -status 2>/dev/null | grep -A5 "OCSP"

# Check if certificate is about to expire (monitoring):
openssl s_client -connect target.com:443 2>/dev/null | \
    openssl x509 -noout -enddate | \
    awk -F= '{print $2}' | \
    xargs -I{} date -d "{}" +%s | \
    awk -v now=$(date +%s) '{days=($1-now)/86400; print "Expires in " int(days) " days"}'

# Monitor certificate changes (detect unexpected reissue):
openssl s_client -connect target.com:443 2>/dev/null | \
    openssl x509 -fingerprint -sha256 -noout
# Compare fingerprint over time — unexpected change = possible attack or cert rotation

# Certificate transparency monitoring (your domain):
curl -s "https://crt.sh/?q=yourdomain.com&output=json" | \
    python3 -c "
import json,sys
certs = json.load(sys.stdin)
for c in certs[:10]:
    print(c['not_before'][:10], c['name_value'], c['issuer_name'][:50])
"
# Review for unexpected certificates issued for your domain

# Generate self-signed certificate (for testing/internal use only):
openssl req -x509 -newkey rsa:4096 \
    -keyout private.pem \
    -out certificate.pem \
    -days 365 \
    -subj "/CN=localhost/O=Test/C=US" \
    -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Timeline:
  SSL 1.0 (Netscape, 1994): Never released (serious flaws found)
  SSL 2.0 (1995):           Released, flaws found quickly
  SSL 3.0 (1996):           Still broken (POODLE 2014 — CVE-2014-3566)
  TLS 1.0 (1999):           RFC 2246, BEAST vulnerability (CVE-2011-3389)
  TLS 1.1 (2006):           Fixed BEAST, still has issues
  TLS 1.2 (2008):           Current acceptable standard
  TLS 1.3 (2018):           Current best practice, significant redesign

Deprecated (should not be used):
  SSL 2.0, SSL 3.0: COMPLETELY BROKEN, disable everywhere
  TLS 1.0, TLS 1.1: Deprecated by RFC 8996 (2021)
                    Chrome/Firefox removed support 2020

  Current standard: TLS 1.2 minimum, TLS 1.3 preferred

TLS provides a secure channel with three properties:

1. Confidentiality: All application data encrypted
   (Before TLS: plaintext visible to any network observer)

2. Integrity: Data cannot be modified without detection
   (HMAC or AEAD authentication tags detect any tampering)

3. Authentication: Server (and optionally client) identity verified
   (Via certificate chain validation)

What TLS does NOT protect:
  - Metadata: IP addresses, TCP ports, timing, volume
  - Server-side application vulnerabilities
  - The DNS lookup that led to the connection
  - Traffic analysis (size and timing patterns)
  - Certificate validity (user must check/browser must validate)

TLS components:
  Record Protocol: Fragments, compresses (deprecated), encrypts, MACs application data
  Handshake Protocol: Negotiates cipher suite, authenticates server, establishes keys
  Alert Protocol: Signals errors and close notifications
  Change Cipher Spec: Signals switch to negotiated cipher (TLS 1.2 only)

TLS 1.2 Cipher Suite naming (verbose):
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  TLS:         Protocol
  ECDHE:       Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral — forward secrecy)
  RSA:         Authentication (certificate type — RSA cert verifies server identity)
  WITH:        Separator
  AES_256_GCM: Symmetric cipher (AES 256-bit in GCM mode)
  SHA384:      HMAC algorithm for integrity (for PRF function in TLS 1.2)

Components:
  Key Exchange: ECDHE > DHE > RSA (RSA key exchange has no forward secrecy — avoid)
  Auth:         ECDSA > RSA (for certificates)
  Cipher:       AES-GCM > AES-CBC (GCM is authenticated, CBC requires separate MAC)
  PRF/HMAC:     SHA-384 > SHA-256 > MD5/SHA-1 (avoid weak hashes)

TLS 1.3 cipher suites (simplified, only 5 allowed):
  TLS_AES_128_GCM_SHA256         (default, fast)
  TLS_AES_256_GCM_SHA384         (high security)
  TLS_CHACHA20_POLY1305_SHA256   (mobile/embedded — faster without AES-NI)
  TLS_AES_128_CCM_SHA256         (constrained environments)
  TLS_AES_128_CCM_8_SHA256       (very constrained IoT)

  Note: TLS 1.3 separates authentication (certificate) from key exchange
        No more RSA key exchange — only ECDHE or DHE
        All TLS 1.3 cipher suites have forward secrecy by default

Weak cipher suites to detect and disable:
  *_NULL_*:    No encryption (plaintext)
  *_EXPORT_*:  40/56-bit keys (FREAK/Logjam attack)
  *_RC4_*:     RC4 stream cipher (broken since 2013)
  *_DES_*:     56-bit DES (trivially cracked)
  *_3DES_*:    112-bit 3DES (SWEET32, slow)
  *_MD5:       MD5 MAC (broken)
  *_SHA:       SHA-1 MAC (weakened)
  *RSA_WITH_*: RSA key exchange (no forward secrecy)
  *_ANON_*:    Anonymous (no authentication — trivial MITM)

TLS 1.2 Full Handshake:

Client                                         Server
  │                                               │
  │──── ClientHello ───────────────────────────→  │
  │  Version: TLS 1.2                             │
  │  Random: 32 bytes (includes timestamp)        │
  │  Session ID: (for resumption)                 │
  │  Cipher Suites: [list of supported]           │
  │  Extensions: SNI, ALPN, elliptic curves...    │
  │                                               │
  │ ←── ServerHello ─────────────────────────── │
  │  Version: TLS 1.2                             │
  │  Random: 32 bytes                             │
  │  Session ID: (new or resumed)                 │
  │  Cipher Suite: SELECTED ONE                   │
  │                                               │
  │ ←── Certificate ─────────────────────────── │
  │  Server's X.509 certificate(s)               │
  │  [Full chain: end-entity + intermediates]     │
  │                                               │
  │ ←── ServerKeyExchange (if ECDHE/DHE) ─────  │
  │  DH parameters + server's DH public value    │
  │  Signed with server's private key            │
  │                                               │
  │ ←── ServerHelloDone ─────────────────────── │
  │                                               │
  │ Client validates:                             │
  │   Certificate chain → trusted CA             │
  │   Server hostname matches SAN                │
  │   Not expired, not revoked                   │
  │   ServerKeyExchange signature valid          │
  │                                               │
  │──── ClientKeyExchange ──────────────────────→ │
  │  Client's DH public value                    │
  │                                               │
  │  [Both compute: Pre-Master Secret from DH]   │
  │  [Both derive: Master Secret]                │
  │  [Both derive: 4 session keys from MS]       │
  │    client_write_key, server_write_key        │
  │    client_write_MAC, server_write_MAC        │
  │                                               │
  │──── ChangeCipherSpec ───────────────────────→ │
  │  "I'll now use the negotiated cipher"        │
  │                                               │
  │──── Finished (encrypted) ───────────────────→ │
  │  HMAC of entire handshake transcript         │
  │  Verifies nothing was tampered during setup  │
  │                                               │
  │ ←── ChangeCipherSpec ─────────────────────── │
  │ ←── Finished (encrypted) ─────────────────── │
  │                                               │
  │ ════════ Application Data (encrypted) ═══════ │

Total round trips: 2-RTT (2 full round trips before data flows)
This latency matters — TLS 1.3 reduces to 1-RTT

TLS 1.3 Handshake — Redesigned for speed and security:

Client                                         Server
  │                                               │
  │──── ClientHello ───────────────────────────→  │
  │  Version: TLS 1.3                             │
  │  Random: 32 bytes                             │
  │  Cipher Suites: [TLS 1.3 only suites]        │
  │  key_share: Client's ECDH public key          │
  │  (Client guesses server's preferred group)    │
  │  supported_versions: [TLS 1.3, TLS 1.2...]   │
  │  pre_shared_key: (for 0-RTT resumption)       │
  │                                               │
  │  [Server can now compute handshake key]       │
  │  [Server begins encrypting immediately]       │
  │                                               │
  │ ←── ServerHello ─────────────────────────── │
  │  Version: TLS 1.3                             │
  │  key_share: Server's ECDH public key          │
  │  (Both now compute shared secret)             │
  │                                               │
  │ ←── {Certificate} ────────────────────────── │ ← Encrypted!
  │ ←── {CertificateVerify} ──────────────────── │ ← Encrypted!
  │  Signature over entire handshake transcript  │
  │ ←── {Finished} ────────────────────────────── │ ← Encrypted!
  │                                               │
  │ Client validates certificate (encrypted)     │
  │                                               │
  │──── {Finished} ─────────────────────────────→ │
  │                                               │
  │ ════════ Application Data (encrypted) ═══════ │

Key improvements in TLS 1.3:
  1-RTT: Faster by one full round trip (vs TLS 1.2's 2-RTT)
  0-RTT: Session resumption can send data in the first message
         (Security tradeoff: 0-RTT data not forward secret, replay risk)

  No more:
    RSA key exchange (eliminated — only ECDHE/DHE)
    CBC cipher suites (GCM and ChaCha20 only)
    MD5, SHA-1 in MAC (SHA-256 minimum)
    DH with <2048-bit primes
    Export cipher suites
    Session renegotiation (was a security issue in TLS 1.2)
    Compression (CRIME attack)

  Certificate and CertificateVerify now encrypted:
    In TLS 1.2, certificate was sent in plaintext → server identity visible to observer
    In TLS 1.3, certificate encrypted → privacy improvement

  Encrypted ClientHello (ECH) — draft standard:
    Extends encryption to ClientHello (SNI currently plaintext)
    When standardised: server hostname hidden from observer

BEAST (CVE-2011-3389):
  Target: TLS 1.0 CBC mode
  Method: Chosen-boundary attack against CBC's predictable IV
  Impact: Decrypt HTTPS session cookies
  Fix: Use TLS 1.2+ (fixed IV handling), use RC4 (now broken too), AES-GCM

CRIME (CVE-2012-4929):
  Target: TLS compression (DEFLATE)
  Method: Compression oracle — inject guesses, observe size change
  Impact: Recover HTTPS cookies
  Fix: Disable TLS compression (disabled by default in all modern implementations)

POODLE (CVE-2014-3566):
  Target: SSL 3.0 CBC mode
  Method: Padding oracle after downgrade to SSL 3.0
  Impact: Decrypt session cookies
  Fix: Disable SSL 3.0 entirely, use TLS 1.2+

Heartbleed (CVE-2014-0160):
  Target: OpenSSL heartbeat extension (TLS extension)
  Method: Missing bounds check — request more data than sent
  Impact: Up to 64KB of server memory per request
          Exposed: private keys, session tickets, passwords, other secrets
  Fix: Patch OpenSSL (1.0.1g), reissue all certificates, rotate secrets

FREAK (CVE-2015-0204):
  Target: Export cipher suites (forced by 90s US regulations)
  Method: Force server to use RSA-EXPORT (512-bit) → factor in hours
  Impact: Decrypt HTTPS connections to affected servers
  Fix: Disable all EXPORT cipher suites

Logjam (CVE-2015-4000):
  Target: DHE-EXPORT (512-bit DH parameters)
  Method: Precompute discrete logarithm table for 512-bit primes
          NSA-scale attack feasible against 1024-bit primes
  Impact: Passive decryption of many HTTPS+VPN connections
  Fix: Minimum 2048-bit DH parameters, use ECDHE instead

ROBOT (2017):
  Target: RSA PKCS#1v1.5 padding in TLS
  Method: Bleichenbacher's 1998 oracle attack resurrected
          Server's different error responses for valid vs invalid padding
  Impact: Decrypt RSA-encrypted TLS sessions (if no forward secrecy)
  Affected: F5, Citrix, Cisco, Palo Alto, Radware, many others
  Fix: Constant-time RSA decryption, use ECDHE (no RSA key exchange)

# TLS security testing:

# Test TLS configuration comprehensively:
# testssl.sh (most comprehensive):
bash testssl.sh target.com:443

# Quick checks:
nmap --script ssl-enum-ciphers,ssl-heartbleed,ssl-poodle,ssl-dh-params \
    -p 443 target.com

# Check supported TLS versions:
for version in ssl2 ssl3 tls1 tls1_1 tls1_2 tls1_3; do
    if openssl s_client -connect target.com:443 -$version 2>/dev/null | \
            grep -q "CONNECTED"; then
        echo "$version: SUPPORTED"
    else
        echo "$version: NOT supported"
    fi
done

# Check certificate details and chain:
openssl s_client -connect target.com:443 -showcerts 2>/dev/null | \
    openssl x509 -noout -text | grep -E "Not After|Signature Algorithm|Public-Key:"

# Decrypt TLS traffic (requires pre-master secret log):
export SSLKEYLOGFILE=/tmp/ssl_keys.log
curl https://target.com/api/data  # Keys logged
# Open in Wireshark: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log

# Test HSTS:
curl -sI https://target.com | grep -i "strict-transport"
# max-age should be ≥31536000 (1 year)
# includeSubDomains recommended
# preload for browser preload list

# Certificate pinning test:
curl -sI --pinnedpubkey sha256//HASH= https://target.com
# If pinning correct: 200
# If wrong pin: SSL error

What breaks when randomness is weak:

Key generation: Predictable private key → attacker knows your key without brute force
AES IV:         Predictable IV → pattern in ciphertext, BEAST-like attacks
ECDSA nonce:    Predictable k → private key recovery (PS3, Android Bitcoin wallet)
Salt:           Predictable salt → precomputed table attacks possible
Session tokens: Predictable tokens → session hijacking without authentication
VPN key:        Predictable key → full traffic decryption (DUHK attack 2017)

PRNG (Pseudo-Random Number Generator):
  Deterministic algorithm that produces "random-looking" numbers
  Seeded with initial value
  Given seed: entire sequence is deterministic

  Examples: rand() in C, Math.random() in JavaScript
  Use for: simulation, games, non-security randomness
  NEVER use for: cryptographic keys, tokens, passwords, security

  Attack: if attacker knows seed (e.g., current timestamp), they can
          predict all "random" numbers → broken crypto

CSPRNG (Cryptographically Secure PRNG):
  Designed to be computationally infeasible to predict next output
  Even with knowledge of all previous output
  Forward secrecy: learning current state doesn't reveal past output
  Backward secrecy: predicting future output is infeasible

  Examples:
  Linux: /dev/urandom (modern Linux: uses CSPRNG, safe for all uses)
  Linux: /dev/random (legacy: blocks until entropy; /dev/urandom is preferred)
  Windows: CryptGenRandom, BCryptGenRandom
  OpenSSL: RAND_bytes()
  Python: os.urandom(), secrets module

/dev/random vs /dev/urandom (Linux):
  Myth: /dev/urandom is weaker than /dev/random
  Truth: Both use same CSPRNG kernel; /dev/random blocks unnecessarily
  Modern Linux (kernel 5.6+): both behave identically
  ALWAYS use: /dev/urandom or the secrets module
  NEVER block applications waiting for /dev/random

Entropy in cryptography: measure of unpredictability (bits)

High entropy: 256-bit key from CSPRNG (truly unpredictable, 2^256 possibilities)
Low entropy:  256-bit key from timestamp (only milliseconds in a day)

Entropy sources (Linux kernel entropy pool):
  Hardware: CPU timing jitter, thermal noise, hardware RNG (RDRAND)
  Devices: Disk I/O timing, network packet arrival timing
  User: Keyboard/mouse timing
  Early boot: Low entropy problem (all sources above unavailable)

The "entropy starvation" problem:
  Embedded systems, VMs, and containers often lack entropy at boot

  Impact: If CSPRNG generates keys before sufficient entropy is collected:
          Keys may be predictable

  Real attack (2012): Heninger et al. analysed millions of RSA public keys
                      Found many shared factors (same primes in different keys)
                      Root cause: entropy-starved key generation at first boot
                      Multiple different devices generated the same "random" primes

  Solution:
  Hardware RNG: Intel RDRAND instruction (hardware true RNG)
  virtio-rng: Feed entropy to VMs from host
  haveged: Software entropy daemon
  rng-tools: Hardware RNG interface daemon

# Cryptographic randomness in practice:

# Generate secure random values:
openssl rand -hex 32                       # 32 bytes = 256-bit random key (hex)
openssl rand -base64 32                    # 32 bytes as base64
openssl rand -out keyfile.bin 32           # Write 32 random bytes to file

# Python — ALWAYS use secrets module for cryptographic randomness:
python3 << 'EOF'
import secrets, os

# Secure token for session IDs, CSRF tokens, etc:
token = secrets.token_hex(32)              # 64-char hex string (256 bits)
print(f"Secure token: {token}")

# Secure random bytes for key material:
key = secrets.token_bytes(32)              # 32 random bytes
print(f"Key (hex): {key.hex()}")

# os.urandom() is equivalent and always cryptographically secure:
key2 = os.urandom(32)
print(f"os.urandom key: {key2.hex()}")

# WRONG: Do not use random module for security:
import random
insecure = random.randbytes(32)
# This is NOT cryptographically secure — don't use for keys/tokens/salts
# random.randbytes looks secure but can be predicted if seed is known
EOF

# Check entropy on Linux:
cat /proc/sys/kernel/random/entropy_avail    # Current entropy bits available
cat /proc/sys/kernel/random/pool_size        # Entropy pool size

# Check hardware RNG availability:
cat /sys/devices/virtual/misc/hw_random/rng_available
ls /dev/hwrng                                # Hardware RNG device

# Install entropy daemon for servers/VMs:
sudo apt install haveged
sudo systemctl start haveged
cat /proc/sys/kernel/random/entropy_avail    # Should be much higher now

# Test PRNG quality (diehard/NIST tests):
openssl rand 1000000 > /tmp/random.bin
ent /tmp/random.bin                          # Entropy test (install: apt install ent)
# Entropy: should be close to 8.00 bits/byte
# Chi-square: should be within expected range
# Serial correlation: should be close to 0.00

Steganography vs Cryptography:

Cryptography:
  "Hello World" → encrypted → "x7Kp2mQ9..." (obviously encrypted)
  Attacker knows: a secret message exists, cannot read it

Steganography:
  "Hello World" hidden inside a photo of a cat
  Attacker sees: a photo of a cat
  Attacker doesn't know: a secret message exists

Combined (crypto + stego):
  Encrypt "Hello World" → encrypt it → hide encrypted data in cat photo
  Even if stego is detected: encrypted content cannot be read
  This is what sophisticated threat actors and C2 channels use

Image Steganography — LSB (Least Significant Bit):

  Each pixel in a 24-bit RGB image has: R(8 bits) G(8 bits) B(8 bits)
  Changing the least significant bit changes colour by 1/256 — visually imperceptible

  Original pixel: R=11010110, G=10010100, B=11100010
  Modified pixel: R=11010111, G=10010100, B=11100011
  (Changed LSB of R and B to embed 2 bits of hidden data)

  Capacity: 3 bits per pixel (one per RGB channel)
  24-bit 1920×1080 image: 1920×1080×3 = 6.2 million bits = ~750KB of hidden data

  Detection: Statistical analysis (chi-square test detects LSB pattern anomalies)
  Steganalysis tools: StegExpose, StegoSuite

Audio Steganography:
  Hide data in audio file LSBs (imperceptible to human hearing)
  Phase modification: hide in phase of audio signal
  Echo hiding: encode data in echo parameters

Network Steganography:
  ICMP payload: hide data in ping packet payload
  TCP timestamp: encode data in TCP timestamp option
  DNS: hide data in subdomain labels or response padding
  HTTP headers: hide in custom headers or timing

  This is particularly relevant for C2 (command and control):
  Malware uses network steganography to blend C2 traffic with legitimate traffic

Offensive uses:
  Data exfiltration: hide stolen data in images uploaded to social media
  C2 communication: hide commands in public social media posts/images
  Malware delivery: embed malware in documents, images

  Real examples:
  Turla APT (2019): hid C2 commands in comments on Britney Spears' Instagram posts
  Duqu malware: used custom steganography to exfiltrate data
  Multiple APT groups: use image steganography for C2 communications

Defensive considerations:
  DLP systems must inspect image content, not just file type
  Network monitoring must analyse payload patterns, not just protocols
  Outbound traffic should be analysed for steganographic channels

# Steganography in practice:

# steghide — hide data in JPEG/BMP/WAV/AU:
sudo apt install steghide

# Hide a file in an image:
steghide embed \
    -cf photo.jpg \              # Cover file (the innocent-looking carrier)
    -sf secret.txt \             # Secret file to hide
    -p "stegopassword"           # Passphrase (encrypts the hidden data)

# Extract hidden data:
steghide extract \
    -sf photo.jpg \              # Stego file
    -p "stegopassword"           # Passphrase
# Extracts secret.txt if passphrase correct

# stegseek — fast steghide password cracker:
stegseek photo.jpg /usr/share/wordlists/rockyou.txt

# zsteg — detect LSB steganography in PNG/BMP:
sudo gem install zsteg
zsteg suspicious_image.png       # Detect hidden data
zsteg -a suspicious_image.png    # Try all methods

# binwalk — find embedded files in any binary:
binwalk suspicious_file.jpg      # Shows embedded files
binwalk -e suspicious_file.jpg   # Extract embedded files

# exiftool — check metadata (stego sometimes in EXIF):
exiftool photo.jpg | grep -v "^$"  # All metadata
exiftool -all= clean_photo.jpg     # Strip ALL metadata

# Detect LSB steganography with statistical analysis:
python3 << 'EOF'
from PIL import Image
import numpy as np

def detect_lsb_stego(filename):
    img = Image.open(filename)
    pixels = np.array(img)

    # Get all LSBs
    lsbs = pixels & 1  # Extract LSB of each channel

    # Calculate expected vs actual distribution
    # In a natural image, LSBs should be ~50% 0, ~50% 1
    # LSB steganography makes it exactly 50% (or different pattern)
    ratio = lsbs.mean()
    print(f"LSB distribution: {ratio:.4f} (natural: ~0.5, suspicious: exactly 0.5)")

    # Chi-square test
    n = lsbs.size
    observed_0 = np.sum(lsbs == 0)
    observed_1 = np.sum(lsbs == 1)
    expected = n / 2
    chi_sq = ((observed_0 - expected)**2 + (observed_1 - expected)**2) / expected
    print(f"Chi-square: {chi_sq:.2f} (low value suggests steganography)")

detect_lsb_stego("photo.jpg")
EOF

State of cryptography in OT/ICS (2024):

No cryptography at all:
  Modbus TCP: no authentication, no integrity, no confidentiality
  DNP3 (baseline): no cryptography (SAv5 adds authentication)
  PROFIBUS: no cryptography
  BACnet: no cryptography in baseline

Why no cryptography:
  1. Designed in 1970s-1980s before network security was a concern
  2. CPU constraints: embedded PLCs lack processing power for crypto
  3. Latency constraints: crypto processing adds microseconds-milliseconds
     unacceptable for hard real-time control loops
  4. Legacy infrastructure: millions of deployed devices cannot be updated
  5. Vendor lock-in: vendors slow to implement standard crypto

Real consequence:
  Any device on the OT network segment can:
  - Read all sensor values (passive Modbus scan)
  - Write to any register/coil (change setpoints, open/close valves)
  - Replay captured commands (repeat a previous command)
  - Inject false commands (fabricate Modbus function codes)
  With no authentication required

IEC 62351 — Security for IEC 61850 and IEC 60870-5-104:
  62351-3: TLS for MMS, ICCP
  62351-4: Authentication for ICCP
  62351-5: Authentication for DNP3 and IEC 60870-5-101/104
  62351-6: GOOSE and Sampled Values authentication (AES-GMAC)
  62351-8: Role-based access control

  Adoption: low — implementation is complex, vendor support varies

OPC-UA Security:
  OPC-UA has built-in security: authentication, signing, encryption
  MessageSecurityMode: None, Sign, SignAndEncrypt
  Sign: Integrity protection (HMAC)
  SignAndEncrypt: Integrity + Confidentiality (AES-256-CBC)
  Certificates: X.509 certificates for server/client authentication

  This is the correct model for new OT deployments
  OPC-UA adoption growing — replacing older proprietary protocols

WirelessHART / ISA100.11a:
  AES-128 encryption for wireless industrial sensors
  CCM (Counter with CBC-MAC) mode — authenticated encryption
  Key management: join keys, session keys

DNP3 Secure Authentication v5 (SAv5):
  HMAC-based challenge-response authentication
  Prevents command injection for DNP3
  Adoption: some power utilities (NERC CIP drives adoption)

IEC 61850 GOOSE Security (IEC 62351-6):
  GOOSE messages authenticated with AES-GMAC
  Prevents forged protection relay commands
  Deployment: rare — latency constraints challenged

TLS deployment challenges in OT:

Certificate management:
  OT devices have long lifespans (10-20 years)
  Annual TLS certificate renewal cycles require:
    - Update process that doesn't interrupt operation
    - Certificate lifecycle management tooling
    - Operator training
  Many OT environments have no process for this

TLS versions on legacy OT:
  Windows CE, Windows XP embedded: support TLS 1.0 only (deprecated)
  Cannot be upgraded without replacing hardware
  Solution: TLS termination proxy (modern TLS toward IT, legacy toward OT device)

Self-signed certificates in OT:
  OT environments often cannot access internet PKI
  Internal CA or self-signed certificates used
  Risk: No validation possible without PKI

TLS for OT communication:
  OPC-UA → TLS 1.2/1.3 for secure machine-to-machine
  Remote access → TLS VPN or TLS-based remote access (not Telnet!)
  Historian → TLS for HTTPS data access from IT

Certificate pinning in OT:
  OT systems can pin specific certificates
  Prevents MITM even with compromised CA
  Requires careful management for certificate rotation

# Cryptography assessment in OT networks:

# Check if OT protocols are running without encryption:
sudo tcpdump -i eth0 -nn 'port 502 or port 20000 or port 2404 or port 44818' | \
    head -20
# If you see traffic: those protocols running in cleartext

# Check if OPC-UA is using TLS:
# Port 4840 = OPC-UA (unencrypted baseline)
# Port 4843 = OPC-UA with TLS
nmap -sV -p 4840,4843 192.168.1.0/24 2>/dev/null

# Test TLS on industrial historian or HMI:
openssl s_client -connect historian-server:443 2>/dev/null | \
    grep -E "Protocol|Cipher|Verify"
# Look for TLS 1.0/1.1 (deprecated) or weak cipher suites

# Check IEC 62351 GOOSE authentication (wireshark):
# Filter: goose
# Check if Security Level > 0 in GOOSE PDU
# Security Level 0 = no authentication (vulnerable)

# Audit OPC-UA security mode:
# Using open62541 or other OPC-UA client:
# python-opcua:
python3 << 'EOF'
try:
    from opcua import Client
    client = Client("opc.tcp://192.168.1.100:4840")
    client.connect()
    # If connected without security: no encryption or authentication
    security_mode = client.get_attribute(1, "SecurityMode")
    print(f"Security Mode: {security_mode}")
    # 1 = None (no security!)
    # 2 = Sign
    # 3 = SignAndEncrypt (correct)
    client.disconnect()
except Exception as e:
    print(f"Connection result: {e}")
EOF