Day 3: Asymmetric Cryptography in TLS

Phase 1 · May 16, 2026

Agenda (2–3 hours)

• Read (45 min): RFC 8446 §4.2.7 (supported_groups), §4.2.3 (signature_algorithms)
• Study (60 min): ECDHE, digital signatures, forward secrecy
• Practice (45 min): Manual ECDH key exchange with openssl
• Challenge (30 min): Rust ECDH exercise

ECDHE: Elliptic Curve Diffie-Hellman Ephemeral

Key agreement, not key transport. Both sides contribute randomness.

Client generates: (priv_c, pub_c)   Server generates: (priv_s, pub_s)
Client sends: pub_c                  Server sends: pub_s
Shared secret: priv_c * pub_s  ==  priv_s * pub_c  (ECDH math)

Ephemeral = keys are generated fresh per handshake, then discarded.

This is what gives TLS 1.3 forward secrecy: compromise of the server's long-term
signing key does NOT decrypt past sessions.

Named Groups in TLS 1.3

RFC 8446 requires implementations to support x25519 and secp256r1.

Digital Signatures in TLS

Used for authentication, not key exchange.

TLS 1.3 signature schemes:

• ecdsa_secp256r1_sha256 — ECDSA on P-256
• ecdsa_secp384r1_sha384 — ECDSA on P-384
• rsa_pss_rsae_sha256/384/512 — RSA-PSS (probabilistic, replaces PKCS#1 v1.5)
• ed25519, ed448 — EdDSA (deterministic, no bad-RNG risk)

In TLS 1.3, the server signs the transcript hash in CertificateVerify — this binds the cert to the handshake.

Practice Exercise

# Generate two ECDH keypairs
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out priv1.pem
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out priv2.pem

# Extract public keys
openssl pkey -in priv1.pem -pubout -out pub1.pem
openssl pkey -in priv2.pem -pubout -out pub2.pem

# Derive shared secrets (both should match)
openssl pkeyutl -derive -inkey priv1.pem -peerkey pub2.pem | xxd | head
openssl pkeyutl -derive -inkey priv2.pem -peerkey pub1.pem | xxd | head

Challenge Assignment

Using the p256 crate in Rust, implement a key exchange:

// Generate two ephemeral ECDH keypairs
// Derive the shared secret from each side
// Assert both sides produce the same shared secret
// Print the shared secret as hex

Then answer in writing: Why does "ephemeral" matter? Specifically: if you captured TLS 1.2 traffic encrypted with a static RSA key, and later obtained the server's private key, what could you decrypt? What about TLS 1.3 with ECDHE?

Add p256 = { version = "0.13", features = ["ecdh"] } to Cargo.toml.

Resources

• RFC 8446 §4.2.7: supported_groups extension
• RFC 8446 §4.2.3: signature_algorithms extension
• p256 crate docs: docs.rs/p256
• Daniel J. Bernstein's Curve25519 paper (optional, for x25519 background)