4.5.3. Post-Quantum Cryptography and Emerging Threats
💡 First Principle: Cryptographic algorithms are building blocks — they are never deployed raw in production. TLS, IPsec, and S/MIME are the protocols that combine these building blocks into practical solutions for specific communication security problems. Understanding which protocol solves which problem, and at which network layer, is directly tested.
TLS (Transport Layer Security):
Protects application layer communications — HTTP (HTTPS), SMTP, IMAP, database connections. Operates at the transport layer (Layer 4), transparently wrapping application layer protocols.
| Version | Status | Notes |
|---|---|---|
| SSL 2.0 / 3.0 | ❌ Prohibited | Multiple critical vulnerabilities; deprecated 2015 (RFC 7568) |
| TLS 1.0 | ❌ Deprecated | POODLE, BEAST vulnerabilities; deprecated 2021 (RFC 8996) |
| TLS 1.1 | ❌ Deprecated | Same as above; deprecated 2021 |
| TLS 1.2 | ✅ Acceptable | Still widely deployed; cipher suite selection critical; DHE/ECDHE required for forward secrecy |
| TLS 1.3 | ✅ Required for new deployments | Removed weak cipher suites; mandates forward secrecy; faster handshake; preferred |
TLS 1.3 improvements: Removed RSA key exchange (no forward secrecy), RC4, DES, 3DES, MD5, SHA-1 from cipher suites. Reduced handshake from 2 round trips to 1 (0-RTT for resumption, with replay attack caveats). All cipher suites in TLS 1.3 use AEAD (authenticated encryption).
TLS 1.3 handshake (1-RTT, RFC 8446): ClientHello (cipher suites + key share) → ServerHello (chosen suite + key share) → server's encrypted Certificate, CertificateVerify and Finished → client verifies the certificate and sends its Finished; application data follows.
TLS termination: terminating TLS at a load balancer or WAF lets it inspect and route traffic, but everything behind it is cleartext unless re-encrypted to the back end. That is acceptable only on an isolated, dedicated segment; across shared or lower-trust networks, re-encrypt (TLS bridging). Pass-through keeps end-to-end encryption but blinds the load balancer to Layer 7.
IPsec:
Operates at the network layer (Layer 3) — encrypts IP packets, transparent to applications. Used for VPNs (site-to-site and remote access) and securing network segments.
Two modes:
| Mode | What's Protected | Use Case |
|---|---|---|
| Transport Mode | Payload only; IP header unencrypted | End-to-end between two hosts; host-to-host VPN |
| Tunnel Mode | Entire original IP packet encapsulated in new IP packet | Network-to-network VPN (gateway-to-gateway); remote access VPN |
Two protocols:
| Protocol | Provides | Header | Notes |
|---|---|---|---|
| AH (Authentication Header) | Integrity + authentication of IP header and payload | Protocol 51 | Does NOT encrypt; cannot traverse NAT (NAT changes IP header, breaking AH) |
| ESP (Encapsulating Security Payload) | Confidentiality + integrity + authentication of payload | Protocol 50 | Encrypts payload; most commonly used; can traverse NAT with NAT-T |
IKE (Internet Key Exchange) — manages security associations (SAs) and key exchange for IPsec:
- IKEv1 Phase 1: Establish secure channel between peers (Main mode or Aggressive mode)
- IKEv1 Phase 2: Negotiate IPsec SA parameters (Quick mode)
- IKEv2: Simplified, more efficient, built-in NAT traversal, better support for mobile clients
Email Security Protocols:
| Protocol | What It Protects | How | Limitation |
|---|---|---|---|
| S/MIME | Email message confidentiality + integrity + nonrepudiation | Asymmetric encryption + digital signatures using X.509 certificates | Requires certificate infrastructure; both parties need certs |
| PGP/GPG | Same as S/MIME | Web of Trust model instead of PKI hierarchy | Difficult key management; "web of trust" doesn't scale for enterprise |
| DKIM | Email authenticity in transit (sender domain verification) | DNS-published public key verifies sending server's signature on headers | Does NOT encrypt; proves the email came from the domain's mail server |
| SPF | Sender IP authorization | DNS TXT record lists authorized IP addresses for a domain | Does NOT encrypt; only validates sending IP |
| DMARC | Policy for SPF/DKIM failures | DNS record tells receiving server what to do when SPF/DKIM fails (quarantine, reject) | Builds on SPF and DKIM; doesn't work without them |
Other emerging-technology threats:
- Prompt injection (LLM applications) — the model receives instructions and user data in the same context window and cannot reliably tell them apart, so input such as "ignore all previous instructions" can override the system prompt. There is no parameterized-query equivalent; defend with input/output filtering, privilege separation and limiting what data and tools the model can reach (OWASP Top 10 for LLM Applications, LLM01).
- Smart contracts — blockchain hashing and consensus protect the integrity of recorded transactions, not the logic of the code that runs on the chain. Contracts carry ordinary application flaws (reentrancy, integer overflow, missing access control), so they need code review and audits like any other software.
⚠️ Exam Trap: DKIM, SPF, and DMARC protect email authenticity and help prevent spoofing — they do NOT encrypt email content. An email protected by all three is still readable in transit by anyone who intercepts it. S/MIME or PGP is required for content confidentiality. These are complementary controls addressing different threats.
Post-quantum cryptography: a large quantum computer running Shor's algorithm would break RSA, Diffie-Hellman and ECC at any practical key size (so a bigger RSA key buys nothing), while Grover's algorithm only halves symmetric strength — AES-256 remains safe. Because adversaries can harvest now, decrypt later, data that must stay secret for years is already exposed. NIST published the first PQC standards in August 2024: FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. The durable response is crypto-agility: inventory where cryptography is used, prioritize key exchange and long-lived certificates and data for migration, and build systems so algorithms can be swapped without re-architecture.
Reflection Question: A healthcare organization wants to ensure that emails containing PHI sent to external specialists are (1) readable only by the intended recipient, (2) verifiably from the healthcare organization's domain, and (3) provably from the specific sending physician. Which combination of protocols addresses all three requirements, and what infrastructure is required to implement it?
