Applied Cryptography (CY-603 (B)) - Unit 5 Short Notes

UNIT 5: Applied Cryptography – Advanced Protocols & Systems

1. Cryptographic Protocols & Secure Communication

Fundamentals of Security Protocols

• Core Goals:

  • Confidentiality: Prevent unauthorized disclosure.

  • Integrity: Detect unauthorized modification.

  • Authentication: Verify identities (peer & data origin).

  • Non-repudiation: Prevent sender denial.

• Common Threat Models:

  • Eavesdropping: Passive interception.

  • Man-in-the-Middle (MITM): Active interception & alteration.

  • Replay Attacks: Resending valid messages.

• Design Principles:

  • Explicit Assumptions: Clearly state trust & channel security.

  • Freshness: Use nonces/timestamps to prevent replay.

  • Key Management: Secure establishment, distribution, rotation.

[!TIP] Exam often asks to design a simple protocol for mutual authentication. Always include nonces & key confirmation steps.

SSL/TLS (Secure Sockets Layer / Transport Layer Security)

• Architecture:

  • Record Layer: Fragmentation, compression, encryption, MAC.

  • Handshake Protocol: Negotiates cipher suite, authenticates, establishes keys.

  • Change Cipher Spec: Signals switch to negotiated crypto.

  • Alert Protocol: Error/warning messages.

• TLS 1.2 vs 1.3 Handshake:

  | Feature | TLS 1.2 | TLS 1.3 | |---|---|---| | RTT for full handshake | 2-RTT | 1-RTT (or 0-RTT with PSK) | | Key Exchange | RSA, DH, ECDH | Only (EC)DH (FS mandatory) | | Cipher Suites | Many (including CBC) | AEAD only (AES-GCM, ChaCha20) | | Version Negotiation | In ClientHello | In ClientHello | | Handshake Encryption | After ServerHello | After ClientHello (1-RTT) |

• Perfect Forward Secrecy (PFS): Compromise of long-term key does not compromise past session keys. Achieved via ephemeral (EC)DH.

• Major Vulnerabilities & Mitigations:

  • BEAST (TLS 1.0 CBC): Mitigate by using TLS 1.1+ or AEAD.

  • POODLE (SSL 3.0 CBC): Disable SSL 3.0.

  • Heartbleed (OpenSSL bug): Patch OpenSSL, reissue certs.

  • FREAK / Logjam: Disable export-grade ciphers, use strong DH groups.

[!TIP] Be ready to draw the TLS handshake message flow for both 1.2 & 1.3. Know which messages are encrypted when.

SSH (Secure Shell)

• Protocol Layers:

  1. Transport Layer: Server authentication, key exchange (DH group exchange), encryption.

  2. Authentication Layer: Client auth (password, public key, keyboard-interactive).

  3. Connection Layer: Multiplexes channels (exec, shell, port-forward).

• Key Exchange: Uses Diffie-Hellman group exchange to negotiate a shared secret. Server host key is verified against ~/.ssh/known_hosts.

• Port Forwarding/Tunneling:

  • Local: ssh -L 8080:internal:80 user@gateway (access internal:80 via localhost:8080).

  • Remote: ssh -R 2222:localhost:22 user@gateway (expose local SSH on gateway's 2222).

  • Dynamic (SOCKS): ssh -D 1080 user@gateway.

IPsec (Internet Protocol Security)

• Modes:

  • Transport Mode: Encrypts only payload (IP header intact). Used for host-to-host.

  • Tunnel Mode: Encrypts entire original IP packet, adds new IP header. Used for VPNs (gateway-to-gateway).

• Protocols:

  | Protocol | Provides | Integrity? | Confidentiality? | |---|---|---|---| | AH (Authentication Header) | Auth & integrity (entire packet) | Yes | No | | ESP (Encapsulating Security Payload) | Auth, integrity, confidentiality (payload) | Optional | Yes |

• Security Associations (SA): Unidirectional connection with:

  • SPI (Security Parameter Index): 32-bit ID in header to lookup SA.

  • IP destination address

  • Security Protocol (AH/ESP)

• IKE/IKEv2: Key management protocol to establish SAs. Uses DH for key exchange, digital signatures for authentication.

2. Email & Messaging Security

PGP (Pretty Good Privacy) / OpenPGP

• Web of Trust vs. PKI:

  • Web of Trust: Decentralized. Users sign each other's keys. Trust is transitive (but limited by "signs" depth).

  • PKI: Centralized (CAs). Trust anchored in root CA certificates.

• Key Rings:

  • Public Key Ring: Stores others' public keys (with trust signatures, user IDs).

  • Private Key Ring: Encrypted (with passphrase) private keys.

• Operations:

  • Signing: Hash(message) → Sign(hash) with priv_key.

  • Encrypting: Session_key → Encrypt(message). Session_key encrypted with recipient's pub_key.

  • Verifying/Decrypting: Reverse process.

• Key Distribution: Keyservers (e.g., keys.openpgp.org), manual exchange, WoT signatures.

S/MIME (Secure/Multipurpose Internet Mail Extensions)

• Certificate-Based: Uses X.509 v3 certificates from a PKI.

• Message Formats:

  • Signed: Clear-text signature or opaque signed data.

  • Enveloped: Encrypted for one or more recipients.

  • Signed-and-Enveloped: Signed then encrypted.

• Comparison with PGP:

  | Feature | PGP | S/MIME | |---|---|---| | Trust Model | Web of Trust | PKI (X.509) | | Key/Cert Format | OpenPGP | X.509 | | Adoption | Individuals, lists | Enterprises | | Integration | Client plugins | Native in Outlook, Apple Mail |

Secure Instant Messaging Protocols

• Signal Protocol (used by Signal, WhatsApp, etc.):

  • X3DH (Extended Triple DH): Initial key agreement using:

    • Alice's identity key (long-term)

    • Bob's identity key, signed prekey, one-time prekey.

    • Provides authentication & PFS for initial session.

  • Double Ratchet Algorithm: Per-message key evolution.

    • KDF Chain: Each message generates new root key & chain key.

    • DH Ratchet: New DH exchange on receiving a message (future secrecy).

    • Message Keys: Derived from chain key for encrypt/decrypt.

• OMEMO: XMPP extension using Signal Protocol.

• OTR (Off-the-Record): Provides deniability (signatures not used) + encryption.

[!TIP] Signal's "future secrecy" means compromise of current state doesn't compromise future messages. Key differentiator from simple PFS.

3. Web Security & HTTPS

HTTPS (HTTP over TLS/SSL)

• Integration:

  • HTTP/1.1 & HTTP/2: One TLS connection per host (multiplexed streams).

  • HTTP/3 (QUIC): TLS 1.3 integrated into QUIC transport (UDP-based). 0-RTT possible.

• Server Authentication: Mandatory via X.509 certificate (CA-signed).

• Client Certificate Auth (mTLS): Optional, mutual auth using client certs.

Web Security Mechanisms

• HSTS (HTTP Strict Transport Security): Strict-Transport-Security: max-age=31536000; includeSubDomains. Forces HTTPS, prevents SSL-stripping.

• Certificate Pinning: Hardcode expected cert/public key hash in app (bypasses CA trust). Risk: update difficulties.

• Certificate Transparency: Public logs of all issued certs. Auditable, detects mis-issuance.

• CSP (Content Security Policy): Mitigates XSS. script-src 'nonce-{random}' allows only scripts with matching nonce. Nonce must be cryptographically random per request.

Web Cryptography API

• Client-side crypto in browsers (JavaScript).

• Key Operations: generateKey, importKey, exportKey (spki, pkcs8, raw, jwk).

• Operations: encrypt, decrypt, sign, verify, digest.

• Use Cases: End-to-end encrypted web apps, secure local storage (IndexedDB).

4. Public Key Infrastructure (PKI) & Key Management

PKI Components & Models

• CA (Certificate Authority): Issues & signs certificates.

• RA (Registration Authority): Verifies identity before CA issues cert.

• Certificate Lifecycle: Issuance → Validation → (Revocation) → Expiration → Renewal → Destruction.

• Revocation Mechanisms:

  | Method | How it Works | Pros | Cons | |---|---|---|---| | CRL (Certificate Revocation List) | CA publishes signed list of revoked serials. | Simple, cached. | Stale, size grows. | | OCSP (Online Certificate Status Protocol) | Client queries OCSP responder for single cert status. | Real-time. | Privacy leak, latency, responder load. | | OCSP Stapling | Server fetches & "staples" OCSP response during TLS handshake. | Privacy, performance. | Server must fetch timely. |

Certificate Standards & Formats

• X.509 v3 Structure:

  
  Certificate
  
  ├── Version (v3)
  
  ├── Serial Number (unique)
  
  ├── Signature Algorithm (e.g., sha256WithRSAEncryption)
  
  ├── Issuer (CA DN)
  
  ├── Validity (notBefore, notAfter)
  
  ├── Subject (entity DN)
  
  ├── Subject Public Key Info (algorithm, pubkey)
  
  └── Extensions [v3]
  
      ├── Key Usage (digitalSignature, keyEncipherment)
  
      ├── Extended Key Usage (serverAuth, clientAuth, codeSigning)
  
      ├── Subject Alternative Name (DNS names, IPs)
  
      ├── Basic Constraints (CA:TRUE/FALSE, pathLen)
  
      └── CRL Distribution Points, Authority Information Access (AIA)
  
  

• Encoding:

  • DER: Binary, ASN.1.

  • PEM: Base64 DER with -----BEGIN CERTIFICATE----- header.

Key Management Challenges

• Distribution:

  • Public Keys: Direct exchange, directories (LDAP), certificates (PKI), PGP keyservers.

  • Symmetric Keys: KDC (Kerberos), asymmetric wrapping (RSA, ECIES).

• Storage:

  • HSM (Hardware Security Module): Tamper-resistant hardware for key storage/operation.

  • TPM (Trusted Platform Module): On motherboard, for device attestation, disk encryption keys.

• Lifecycle: Generation (CSPRNG!) → Activation → Rotation → Expiration → Destruction (zeroize).

5. Blockchain & Cryptocurrency Cryptography

Blockchain Fundamentals

• Structure:

  • Block: Header (prev_hash, merkle_root, nonce, timestamp) + transactions.

  • Chain: Each block's header hash links to next via prev_hash. Any change breaks chain.

  • Merkle Tree: Binary hash tree of transactions. MerkleRoot = hash(hash(Tx1)+hash(Tx2)).... Allows SPV (Simplified Payment Verification) with just Merkle proof.

• Consensus:

  • PoW (Proof-of-Work): Miners find nonce s.t. hash(block_header) < target. Energy-intensive.

  • PoS (Proof-of-Stake): Validator chosen based on stake (coins locked). Less energy.

• Cryptographic Hashing: SHA-256 (Bitcoin), Keccak-256 (Ethereum). Properties: preimage resistant, collision resistant, avalanche.

Bitcoin & Ethereum Cryptography

• Digital Signatures:

  • Bitcoin: ECDSA over secp256k1 curve.

    • Sign: s = k⁻¹ (z + r·priv_key) mod n where r = (k·G).x mod n.

    • Verify: Check u1 = z·s⁻¹ mod n, u2 = r·s⁻¹ mod n, R = u1·G + u2·PubKey, R.x mod n == r.

  • Ethereum: Same ECDSA, but transitioning to Schnorr (BIP-340) for better efficiency & aggregation.

• Address Generation:

  1. Generate priv_key (random 256-bit).

  2. Pub_key = priv_key · G (uncompressed or compressed).

  3. address = last20bytes(keccak256(uncompressed_pubkey)) (Ethereum).

  4. Bitcoin: RIPEMD160(SHA256(pubkey)), then base58check with version byte.

• Transaction Structure:

  • Bitcoin: Inputs (prev tx refs, unlocking script), Outputs (amount, locking script/ScriptPubKey). Scripts are stack-based.

  • Ethereum: nonce, gasPrice, gasLimit, to, value, data, v,r,s (ECDSA signature).

Smart Contracts & Security

• Primitives: Hashing (keccak256), signatures (ecrecover), random numbers (vulnerable!).

• Common Vulnerabilities:

  • Reentrancy: Call external contract before state update (The DAO hack). Mitigate: Checks-Effects-Interactions pattern, reentrancy guard.

  • Integer Overflow/Underflow: Use SafeMath libraries (Solidity <0.8) or built-in checks (>=0.8).

• Zero-Knowledge Proofs:

  • zk-SNARKs (Ethereum ZK-Rollups): Trusted setup, succinct, non-interactive.

  • zk-STARKs: No trusted setup, larger proof size, post-quantum resistant.

6. Advanced Cryptographic Applications

Secure Multi-Party Computation (MPC) & Threshold Cryptography

• MPC Principle: Jointly compute f(x1, x2, ..., xn) without revealing individual xi.

• Threshold Cryptography: Split private key into n shares, need t of n to sign/decrypt.

  • Threshold ECDSA: Complex due to non-linear s in signature. Protocols like GG18.

  • BLS Signatures: Naturally support aggregation & threshold (pairing-based).

• Applications: Distributed key generation (DKG) for wallets, secure custody.

Homomorphic Encryption (HE)

• Types:

  • Partially Homomorphic:

    • RSA (Multiplicative): E(a)·E(b) = E(a·b).

    • Paillier (Additive): E(a)·E(b) = E(a+b).

  • Somewhat Homomorphic (SHE): Supports limited operations (e.g., some additions & multiplications).

  • Fully Homomorphic (FHE): Arbitrary computations. Gentry's scheme (2009) using bootstrapping.

• Use Cases: Encrypted database queries, private ML inference, secure voting.

Post-Quantum Cryptography (PQC) in Practice

• NIST Standardization (Round 3 Finalists):

  • KEM: CRYSTALS-Kyber (lattice-based, leader).

  • Signatures: CRYSTALS-Dilithium (lattice), FALCON (lattice), SPHINCS+ (hash-based).

• Migration Strategies:

  • Hybrid Schemes: Combine classical (e.g., X25519) with PQC (e.g., Kyber) in TLS 1.3. Security if either is broken.

  • Algorithm Agility: Design protocols to negotiate/upgrade algorithms easily.

• Threats: Shor's algorithm breaks RSA, ECC, DH. Grover's affects symmetric key lengths (double key size).

7. Implementation & Side-Channel Considerations

Cryptographic Engineering Pitfalls

• Use Libraries, Not Home-Grown: Use libsodium, OpenSSL (high-level API), BouncyCastle.

• Randomness: CSPRNG essential. /dev/urandom (Linux), CryptGenRandom (Windows), getrandom(). Never rand().

• Padding Oracle Attacks (CBC mode): Attacker learns if padding valid. Mitigate: Use AEAD (GCM, ChaCha20-Poly1305), constant-time padding check.

Side-Channel Attacks & Countermeasures

• Types:

  • Timing: Measure operation time (e.g., RSA private key ops, string compares).

  • Power Analysis (SPA/DPA): Measure device power consumption.

  • Electromagnetic (TEMPEST): Radiated signals.

  • Cache Timing (e.g., Meltdown, Spectre).

• Countermeasures:

  • Constant-Time: Avoid branches/secrets in timing. Use constant_time_compare().

  • Masking: Split secrets into random shares (e.g., secret = s1 ⊕ s2).

  • Blinding: Randomize computation (e.g., RSA: compute (m·r^e)^d · r^{-1}).

  • Hardware: Secure elements, HSMs, TPMs with physical shielding.

8. Case Studies & Real-World Protocols

Signal Protocol Deep Dive

• X3DH (Initial Key Agreement):

  
  Alice's keys: IDa (long-term), SPKb (signed prekey), OPKb (one-time prekey, optional)
  
  Shared secret = DH(IDa, IKb) ⊕ DH(SPKb, IDa) ⊕ DH(OPKb, IDa) [if OPK used]
  
  

  Provides MITM resistance (long-term keys signed) & PFS (ephemeral keys).

• Double Ratchet:

  • KDF Chain: Root key → Chain key (per message direction) → Message keys.

  • DH Ratchet: On receiving message with new DH public key, perform new DH exchange → new root key.

  • Guarantees future secrecy: New DH breaks link to past chain keys.

WireGuard VPN Protocol

• Design: Minimalist (~4k LOC). Modern crypto stack:

  • Key Exchange: Curve25519 (ECDH).

  • Symmetric: ChaCha20 (encryption), Poly1305 (auth).

  • Hash: BLAKE2s.

• Stateful Datagram: Each packet has counter, prevents replay. Key rotation after every message.

• Simple Config: Public keys only (no certificates). Peer-to-site or site-to-site.

DNSSEC (Domain Name System Security Extensions)

• Goal: Provide origin authentication & integrity for DNS data.

• Key Records:

  • DNSKEY: Public key (KSK - key signing key, ZSK - zone signing key).

  • RRSIG: Signature for a record set (covered RRset).

  • DS (Delegation Signer): Hash of child zone's DNSKEY, stored in parent zone. Creates chain of trust.

• Validation: Resolver fetches DNSKEY → RRSIG → verifies with DNSKEY → follows DS chain to trust anchor (root key).

• DANE (DNS-based Authentication of Named Entities): Use DNSSEC to bind TLS certs to domain names (replaces CA for that domain).

9. Regulatory & Compliance Aspects

Standards & Regulations

• FIPS 140-2/3: Security requirements for cryptographic modules (US govt). Levels 1-4 (physical security, EMI, etc.).

• PCI DSS: For payment card data. Requires strong cryptography (TLS 1.2+, AES, SHA-2). Never use SSL/TLS 1.0, MD5, SHA-1.

• GDPR: Encryption as "appropriate technical measure" for data protection. Breach notification may be waived if data encrypted.

Export Controls & Legal Considerations

• Wassenaar Arrangement: Controls dual-use goods (including "strong" crypto). Key length limits historically (now largely relaxed for "mass-market").

• ITAR (US): Controls defense-related items. Strong crypto can be considered "munitions".

• Country Restrictions: Some countries (e.g., China, Iran) have mandatory key escrow or ban certain crypto.

[!TIP] Know which standards mandate which algorithms (e.g., PCI DSS forbids SHA-1, SSL 3.0). Always check latest version.