07 — Cryptographic Protocols

Protocols combine primitives (ciphers, hashes, signatures) into interactions between parties. Here: TLS, SSH, IPsec, Kerberos, OAuth/OIDC, Signal, MLS, Noise, WireGuard, OPAQUE, and relevant classical protocols.

1. SSL / TLS — evolution

SSL 1.0 (Netscape 1994) ❌

Never released publicly. Elementary flaws discovered internally.

SSL 2.0 (1995) ❌

• MAC and encryption use the same key.
• Header traffic not authenticated.
• Vulnerable to truncation attacks.
• Padding oracle issues.
• Deprecated RFC 6176 (2011). Removed from every browser ~2015.

SSL 3.0 (1996) ❌

• MAC with SHA-1 but does not cover everything.
• CBC vulnerable (BEAST, POODLE).
• POODLE (2014) — Padding Oracle On Downgraded Legacy Encryption. Killed SSL 3.0 in browsers Q4/2014.

TLS 1.0 (RFC 2246, 1999) ❌

Rename of SSL 3.1 (Netscape vs IETF politics). Same algorithms. BEAST (2011) demonstrated a problem with CBC IV chaining.

TLS 1.1 (RFC 4346, 2006) ❌

BEAST fix: explicit IV per record. Fell into disuse; deprecated along with 1.0 in 2020 (RFC 8996).

TLS 1.2 (RFC 5246, 2008) ⚠️

• Supports SHA-256, AES-GCM, AEAD.
• Still allows RSA key transport (no forward secrecy).
• Still allows cipher suites with RC4, 3DES, CBC.
• Secure configuration is possible but requires diligence.
• Status: still dominant. Should be configured with only ECDHE + AEAD cipher suites.

Recommended TLS 1.2 cipher suites:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-CHACHA20-POLY1305

TLS 1.3 (RFC 8446, 2018) ✅

Deep redesign:

• Removes RSA key transport (always ECDHE/DHE → forward secrecy mandatory).
• Removes RC4, 3DES, MD5, SHA-1, CBC modes (all), static DH.
• Removes compression (CRIME).
• Removes renegotiation.
• Only 5 cipher suites; all AEAD.
• 0-RTT (zero round-trip resumption) — performance but with replay caveats.
• Handshake encrypted after ServerHello.
• Unified HKDF-based key schedule.

TLS 1.3 cipher suites (all mandatory):

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256 (mandatory per RFC)
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Key exchange groups: secp256r1 (P-256), secp384r1, secp521r1, X25519, X448, plus X25519MLKEM768 (post-quantum hybrid, draft-ietf-tls-hybrid-design).

TLS 1.3 handshake (simplified)

ClientHello [random, cipher_suites, key_share, signature_algorithms, ...]
  →
ServerHello [random, cipher_suite, key_share, ...]
{EncryptedExtensions}
{Certificate}
{CertificateVerify}
{Finished}
  ←
{Certificate*}      // optional mTLS
{CertificateVerify*}
{Finished}
  →
[Application Data]
  ⇄

{...} = encrypted with handshake traffic secret derived from ECDHE.

Post-quantum migration

• X25519MLKEM768 — Cloudflare/Google rolling out in 2024–2025. ClientHello carries both key_shares; server chooses.
• Traditional servers still on pure ECDHE.
• Complete migration expected 2028–2032.

Historical TLS 1.2/1.3 flaws

Useful extensions

• SNI (Server Name Indication, RFC 6066) — host header in ClientHello.
• ALPN (RFC 7301) — Application-Layer Protocol Negotiation (HTTP2, HTTP3).
• ECH (Encrypted Client Hello, draft) — encrypts SNI; replaces ESNI. Uses HPKE.
• Certificate Transparency (RFC 6962) — public logs of cert issuances.
• OCSP Stapling (RFC 6066) — server sends OCSP response, client does not query the CA.
• 0-RTT — TLS 1.3 early data with PSK. Replay risk.
• TLS-PSK — pre-shared key, no cert.

Cert validation chain

Root CA (offline, in HSM)
  ↓
Intermediate CA (online)
  ↓
End-entity cert (server)

Client loads a Root store (Mozilla NSS, Microsoft, Apple, Google CRLSet). Each intermediate signs the next.

Certificate Transparency (CT) — public append-only signed log. Browsers require an SCT (Signed Certificate Timestamp). Detects mis-issued certs.

2. SSH (Secure Shell)

History

• 1995: Tatu Ylönen (Finland) — SSH-1.
• 1996: OpenSSH fork of SSH-1.2.12 (last free one).
• 1997–2006: IETF standardizes SSH-2 (RFC 4251–4254).
• 2006: SSH-2 mainstream.

SSH-2 layers

1. Transport (RFC 4253) — KEX, encryption, MAC, server authentication.
2. User auth (RFC 4252) — password, public key, host-based, GSSAPI.
3. Connection (RFC 4254) — multiplex channels (shell, exec, port forward, X11).

KEX

• diffie-hellman-group14-sha256 (RFC 8268)
• diffie-hellman-group-exchange-sha256
• ecdh-sha2-nistp256384521
• curve25519-sha256@libssh.org / curve25519-sha256 (modern default)
• sntrup761x25519-sha512@openssh.com (PQC hybrid, OpenSSH 9.0+, April 2022)

Host keys

• ssh-rsa (legacy, broken SHA-1 hash; deprecated as default in OpenSSH 8.2+)
• rsa-sha2-256, rsa-sha2-512
• ecdsa-sha2-nistp256384521
• ssh-ed25519 (recommended, default since 7.x)

User keys

~/.ssh/id_ed25519 recommended instead of id_rsa. RSA 4096 OK as an alternative.

Historical vulnerabilities

• CRC-32 compensation attack (1998, SSH-1) — RC4-MD5.
• Plaintext recovery in CBC mode (Albrecht et al. 2009) — required 8 GB of traffic.
• Roaming feature client bug (CVE-2016-0777, 2016) — leaked the private key.
• Terrapin (CVE-2023-48795, Dec/2023) — truncation attack on SSH BPP. A MITM attacker in the handshake cuts extension negotiation. Mitigated by strict KEX in OpenSSH 9.6+ and libssh 0.10.6+.

Hardening 2026

HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

3. IPsec / IKE

Network-layer encryption. RFC 4301 (architecture), RFC 7296 (IKEv2).

Components

• AH (Authentication Header, RFC 4302) — integrity + authenticity (no confidentiality). Rarely used today.
• ESP (Encapsulating Security Payload, RFC 4303) — confidentiality + integrity.
• IKE (Internet Key Exchange) — negotiates SAs (Security Associations) and keys.

Modes

• Transport mode — IP header preserved; payload encrypted. Host-to-host.
• Tunnel mode — IP header encrypted inside; new outer header. Gateway-to-gateway VPN.

IKEv1 ❌

RFC 2409 (1998). Aggressive Mode has PSK offline crack (cipherspark 2018 demo). Main Mode more robust but complex.

IKEv2 ✅

RFC 7296. Radical simplification: 1 RTT setup, mobility (RFC 4555 MOBIKE), EAP auth.

Recommended cipher suites

• AES-GCM-128 or AES-GCM-256 (RFC 4106)
• ChaCha20-Poly1305 (RFC 7634)
• Diffie-Hellman group 19 (256-bit ECP) or 20 (384-bit ECP) or 31 (X25519)

IKE_AUTH with certificates or PSK

Flaws

• CVE-2018-5389 — Aggressive Mode PSK offline.
• strongSwan / Libreswan stack code: several CVEs over the years; keep it updated.

Modern alternative: WireGuard

See §10.

4. Kerberos

MIT Athena Project, 1980s. RFC 4120 (V5, 2005). Backbone of Active Directory.

Components

• KDC (Key Distribution Center): issues tickets.
• AS (Authentication Service): issues the TGT (Ticket-Granting Ticket).
• TGS (Ticket-Granting Service): issues service tickets.
• Principal: identity (user@REALM, host/fqdn@REALM).

Flow

1. AS-REQ: client sends username; AS responds with a TGT encrypted with the password hash.
2. Client decrypts the TGT with the password; now has a valid TGT (and a session key with the TGS).
3. TGS-REQ: client presents the TGT + requested service principal; TGS responds with a service ticket.
4. AP-REQ: client presents the service ticket to the service.

Crypto

• DES (deprecated)
• 3DES (deprecated)
• AES-128/256-CTS-HMAC-SHA1-96 (RFC 3962)
• AES-128256-CTS-HMAC-SHA256384-192 (RFC 8009)

Vulnerabilities

• Golden Ticket: compromised the krbtgt hash (the TGS principal); can forge any TGT. AD requires a double rotation to invalidate.
• Silver Ticket: forges a service ticket without talking to the KDC.
• Kerberoasting: requests service tickets with a compromisable SPN, then offline-cracks the key (= the account's password hash).
• AS-REP Roasting: users with DONT_REQ_PREAUTH allow a dump.
• Zerologon (CVE-2020-1472) — Netlogon protocol bug: AES-CFB8 with all-zero IV accepts all-zero plaintext → zeroes the DC's password. Critical in Sep/2020.

5. OAuth 2.0 + OpenID Connect

Not cryptography per se; an access-delegation protocol.

OAuth 2.0 (RFC 6749, 2012)

Roles:

• Resource Owner (user)
• Client (app)
• Authorization Server (Koder ID, Google, etc.)
• Resource Server (API)

Flows:

• Authorization Code + PKCE — current standard for mobileSPAweb.
• Implicit Flow — deprecated (token in URL fragment, leaks).
• Client Credentials — service-to-service.
• Device Authorization Flow (RFC 8628) — TVs, CLIs.
• Refresh Token — long-lived re-auth.

PKCE (RFC 7636)

Random code_verifier; code_challenge = SHA256(verifier). Binds the authorization code to the client session. Mandatory for public clients.

OpenID Connect (OIDC)

Identity layer on top of OAuth 2.0. Server issues an id_token (JWT) with the user's claims.

JWT (RFC 7519)

header.payload.signature

• Header: alg, typ.
• Payload: claims (iss, sub, aud, exp, iat, jti, etc.).
• Signature: signature over header.payload.

Algorithms:

• HS256384512 — HMAC, symmetric (shared secret).
• RS256384512 — RSA-PKCS#1 v1.5 SHA-*.
• PS256384512 — RSA-PSS.
• ES256384512 — ECDSA.
• EdDSA — Ed25519 (RFC 8037).

Common JWT flaws

• alg: none accepted by careless libs (CVE-2015-9235).
• alg: HS256 with an RSA pubkey as the secret (CVE-2015-2951).
• kid path traversal if kid is used as a filename.
• Algorithm confusion between RS256 and HS256.
• JWT note: never trust a JWT that came from the client — always validate the signature, exp, aud, iss.

Koder ID

Stack spec: specs/auth/oauth-flow.kmd — slug koder-id, post-auth dashboard, no local form, deep-link preserve, R1-R12.

6. Signal Protocol

End-to-end encryption messaging. Open Whisper Systems (Moxie Marlinspike, Trevor Perrin) — now the Signal Foundation.

Components

1. X3DH (Extended Triple Diffie-Hellman) — initial key agreement with published pre-keys.
2. Double Ratchet — DH ratchet (new key per message) + symmetric ratchet (KDF per message) → forward secrecy + post-compromise security.
3. Sesame — multi-device session management.

X3DH

Server hosts:

• Long-term identity key (IK_B) — Ed25519.
• Signed pre-key (SPK_B) — rotated weekly.
• One-time pre-keys (OPK_B) — used once.

Alice fetches Bob's bundle. Compute:

DH1 = DH(IK_A, SPK_B)
DH2 = DH(EK_A, IK_B)
DH3 = DH(EK_A, SPK_B)
DH4 = DH(EK_A, OPK_B)
SK = HKDF(DH1 \\\| DH2 \\\| DH3 \\\| DH4)

Deniability: anyone with the identity keys could forge — Alice has cryptographic deniability.

Double Ratchet

For each message:

• Symmetric ratchet: \(\text{chain\_key} \to (\text{msg\_key}, \text{chain\_key}')\) via HMAC-SHA256.
• DH ratchet: upon receiving a new message with a new DH pubkey, advance the DH chain: new DH share → new root key → new chain keys.

Result:

• Forward secrecy: an old message is not recoverable even with the current key.
• Post-compromise security: after compromising the state, the next DH ratchet recovers security.

Adoption

• Signal app
• WhatsApp (2016)
• Facebook Messenger Secret Conversations
• Google Allo (discontinued)
• Skype private conversations
• KaKaoTalk

PQXDH (Signal, 2023)

PQC replacement for X3DH. Combines X25519 + ML-KEM-1024. Hybrid model: an attack must break both.

7. MLS — Messaging Layer Security

RFC 9420 (Jul/2023). IETF standardization of E2E for groups.

Motivation

Signal scales poorly to large groups (each message encrypts to N members). MLS uses TreeKEM: a binary tree, each node has a key; a change propagates in \(O(\log n)\).

Components

• Asymmetric Ratchet Tree (RT): a tree with keys at each node.
• TreeKEM: efficient derivation of group keys.
• Welcome message: a new member receives the ratchet state.
• Commit: changes the group state (add, remove, update).

Adoption

• WebEx (Cisco)
• RingCentral
• Wickr (AWS)
• Implementations: OpenMLS (Rust), mlspp (Cisco C++)

8. Noise Protocol Framework

Trevor Perrin, 2015–2018. noiseprotocol.org. A framework for building secure protocols. Not a single protocol.

Patterns

Notation: each handshake = a sequence of tokens (e, s, ee, es, se, ss). Examples:

• N: one-shot encryption to a pre-known recipient.
• K: known recipient + authenticated sender.
• X: full mutual auth + encrypted transport.
• IK (interactive K): used by WireGuard.
• XX: mutual auth, cert exchange.

Used in

• WireGuard: Noise_IKpsk2.
• Lightning Network: Noise_XK.
• WhatsApp protocol stack (parts).
• Nym, Wesh, Slack Connect.

9. WireGuard

Jason Donenfeld, 2015–2018. Merged into the Linux kernel 5.6 (Mar/2020).

Design

• 4000 lines of kernel C (vs 100k+ for the IPsec stack).
• Cryptographic agility: rejected by design. Fixed algorithms:
  • Curve25519 (ECDH)
  • ChaCha20-Poly1305 (AEAD)
  • BLAKE2s (hash)
  • HKDF
• No PKI; each peer has its pubkey listed in config.
• UDP only, single port.

Handshake

Noise_IKpsk2 — 2 messages, 1 RTT. Recovers from hibernation with a cookie.

Privacy

No identity in packets. Stateless transport packets are indistinguishable without the correct key.

Limitations

• No dynamic peers (use Tailscale/Headscale on top).
• No TCP fallback (use a TCP-tunneling overlay).
• No PQC (proposed: boringtun PQ fork experimented in 2023).

10. OPAQUE — PAKE

RFC 9497 (2024). PAKE (Password-Authenticated Key Exchange) that avoids the server storing the password or any derivative.

• Server stores an OPRF(salt, password) envelope, without ever seeing the password.
• Even if the server leaks, offline dictionary attack is impossible.
• Replaces the "send password, server bcrypt-compares" system.

Used experimentally at Cloudflare, ProtonMail planning, future Keybase.

Other PAKEs

• SRP (Secure Remote Password) — old, still used in 1Password until 2024.
• SPAKE2, J-PAKE, CPace — variants.

11. Email & Documents

PGP / OpenPGP

RFC 4880 (legacy), RFC 9580 (2024 — Crypto Refresh).

• Web of trust (vs hierarchical PKI).
• Ciphers: AES, Camellia; hashes: SHA-2, SHA-3; sigs: RSA, ECDSA, EdDSA, Ed25519.
• RFC 9580 adds Curve25519, BLAKE2, Argon2.

Modern criticisms:

• Long-term keys (no forward secrecy).
• Terrible UX.
• Divergent implementations.
• EFAIL (2018) — backchannel via HTML rendering.
• SOP-spec (Stateless OpenPGP) attempts to clean up implementations.

S/MIME (RFC 8551)

PKCS#7 / CMS for email. CA-based PKI. Less popular outside corporate.

age (Filippo Valsorda 2019)

Replaces PGP for file encryption.

• No long-term identities; each file has an ephemeral key.
• X25519 + ChaCha20-Poly1305 + scrypt.
• SSH key compatibility (Ed25519, RSA).
• age CLI, libsodium-style.

12. DNSSEC, DoT, DoH, DoQ

DNSSEC (RFC 4033/4035)

Signs DNS records. DS / DNSKEY chain of trust. Modern algorithms: ECDSA P-256, Ed25519, Ed448. Legacy algorithms still in use: RSA-SHA256, RSA-SHA1 (prohibit).

DNS-over-TLS (DoT, RFC 7858)

Port 853. TLS over a dedicated port. Server cert validated.

DNS-over-HTTPS (DoH, RFC 8484)

Port 443. Over HTTPS. Harder to censor but mixes with web traffic.

DNS-over-QUIC (DoQ, RFC 9250)

DNS over QUIC. Lower latency.

ODoH, Oblivious DoH (RFC 9230)

Privacy: client → proxy → resolver. The resolver does not know the client IP; the proxy does not see the queries.

13. QUIC and HTTP/3

QUIC (RFC 9000–9002, 2021) — transport over UDP with TLS 1.3 built in. Multiplexing without head-of-line blocking. HTTP/3 (RFC 9114) is HTTP over QUIC.

All crypto = TLS 1.3 with an extension to integrate into the QUIC packets.

14. ACME (Let's Encrypt)

RFC 8555 (2019). A protocol for automatic cert issuance. The client proves control of the domain via challenges:

• HTTP-01: serve a token at /.well-known/acme-challenge/.
• DNS-01: create a TXT record _acme-challenge.example.com.
• TLS-ALPN-01: serve a special ALPN cert.

Implementations:

• certbot (EFF, original).
• acme.sh (bash).
• lego (Go, used by Caddy/Traefik).
• dehydrated (bash, minimal).
• Koder Jet native ACME.

Koder Stack: services/foundation/certs on s.khost1:9421 does DNS-01 via the ClouDNS API. LE staging confirmed.

15. WebAuthn / FIDO2

W3C + FIDO Alliance, 2019.

• Public-key authentication with hardware (YubiKey, Titan, Touch ID).
• Resists phishing (origin binding).
• Crypto: ECDSA P-256, Ed25519, optional RSA.
• Optional attestation (proves the authenticator is genuine).

Adoption: Google, Apple, Microsoft Passkeys (2022–) replacing passwords. A Passkey = a WebAuthn credential synced across iCloud / Google account.

16. Tor / mix-nets / Loopix

Anonymity protocols.

• Tor: 3-hop onion routing with layered TLS. AES-128-CTR + DH ECDH. Hidden services .onion.
• I2P: garlic routing.
• Mixnets (Loopix, Nym): cover traffic, mixing nodes. Latency-tolerant.

17. Summary: protocols by use (2026)

18. Cross-reference

• Primitives used: 04-symmetric.md, 05-asymmetric.md, 06-hash-and-mac.md.
• Attacks against: 11-attacks.md (BEAST, POODLE, FREAK, Logjam, DROWN, Heartbleed, ROBOT, Terrapin).
• PQC integration: 08-post-quantum.md.
• Identities / certs / CAs: 09-confidential-computing.md + 13-incidents.md (DigiNotar, Comodo).
• Koder Stack usage: 14-koder-applied.md.