A key distribution center works well where users and services can register with a common authority. Extending that arrangement to the public web would require browsers and unrelated websites to share secrets with compatible key servers. Certificates let a browser authenticate a website without that advance registration.

A certificate authority signs the binding between a public key and a name ahead of time. A browser verifies the certificate chain using its trust store and checks that the certificate is valid for the requested domain. The authority does not have to participate in the key exchange, although certificate validation may involve obtaining revocation information.

Authenticating with a Signature

Challenge-response authentication works with a key pair as well as with a shared key. The two versions differ only in what Alice computes and what Bob needs to check it. With a shared key \(K\), Alice returns a MAC:

1. \(B \rightarrow A: r\)

2. \(A \rightarrow B: \operatorname{HMAC}_K(r)\)

With a key pair, Alice returns a signature made with her private key, written \(\operatorname{Sig}_A(r)\):

1. \(B \rightarrow A: r\)

2. \(A \rightarrow B: \operatorname{Sig}_A(r)\)

Bob verifies the signature with Alice’s public key, which he obtained from her certificate.

A correct signature on a fresh nonce shows that Alice’s private key was used in this exchange. Bob needs only her public key to verify it, so he does not need to store a secret that would let an attacker impersonate Alice. A signature on a nonce alone can still be relayed. A complete protocol also binds the proof to the intended parties and their exchange.

For a secure conversation, the parties also need keys that protect the data sent after authentication.

Sending a Key Under a Public Key

One way to establish a shared key is public key transport. The client generates a random secret and encrypts it with the server’s authenticated public key. The server decrypts it with its private key, and both parties derive session keys from the secret. Transport Layer Security (TLS), the protocol behind HTTPS, supported this approach using RSA through version 1.2.

RSA key transport makes past sessions depend on the server’s long-term private key. An adversary who records a handshake and its encrypted traffic can decrypt that traffic if it later obtains the corresponding private key.

In 2013, the U.S. Federal Bureau of Investigation (FBI) demanded the TLS private key of Lavabit, an encrypted email service whose users included Edward Snowden. Although the investigation concerned one user, the key could expose other users’ connections that relied on RSA key transport. The owner, Ladar Levison, initially supplied eleven printed pages in four-point type. After a court ordered a usable digital copy, he provided one and shut the service down on August 8, 2013.

Keys can also leak through software flaws. Heartbleed, disclosed in April 2014, exposed memory from servers using vulnerable versions of the OpenSSL cryptographic library. Researchers demonstrated that the leaked memory could include private keys.

Diffie-Hellman and the Adversary in the Middle

Diffie-Hellman key agreement lets two parties compute a shared secret from public values. Using agreed public parameters \(p\) and \(g\), Alice picks a secret \(a\) and sends \(g^a \bmod p\). Bob picks a secret \(b\) and sends \(g^b \bmod p\). Each raises the received value to its own secret exponent, arriving at \(g^{ab} \bmod p\). The rest of this section omits the \(\bmod p\).

With suitable parameters, no efficient method is known for computing this shared secret from the public values alone on a non-quantum computer. Solving a discrete logarithm to recover either exponent would defeat this protection. Elliptic-curve Diffie-Hellman (ECDH) performs key agreement with smaller public values at comparable security.

Diffie-Hellman does not authenticate anyone. Nothing in \(g^a\) indicates who sent it.

An adversary in the middle can exploit this. When Alice sends \(g^a\), the adversary keeps it and sends Bob its own value, \(g^m\). When Bob replies with \(g^b\), the adversary keeps that and sends Alice \(g^m\). Alice computes \(g^{am}\) and believes she shares it with Bob. Bob computes \(g^{bm}\) and believes he shares it with Alice. The adversary knows both keys. It decrypts each message from Alice, reads or changes it, and re-encrypts it for Bob.

Signing the Exchange

Signatures can bind the key exchange to an authenticated identity. The signed data should cover both parties’ contributions and the context of the exchange, including their roles. The verifier checks the signature using a trusted public key, often supplied in a certificate. An adversary that substitutes its own Diffie-Hellman value cannot produce a matching signature from the expected party.

In RSA key transport, the server’s private key decrypts the shared secret. In a signature-authenticated Diffie-Hellman exchange, the long-term private key authenticates the exchange instead. The shared secret comes from the Diffie-Hellman private values.

Hybrid Cryptosystems

Public-key cryptography is much slower than symmetric encryption. Encrypting data directly with RSA also produces a larger ciphertext block for each plaintext block. Protocols therefore use public-key operations to authenticate parties and establish a shared key, then protect the data with symmetric authenticated encryption. This combination is a hybrid cryptosystem. TLS uses this design. So does encrypted email based on Pretty Good Privacy (PGP), which encrypts each message with a random symmetric key and encrypts that key with the recipient’s public key.

The word hybrid also appears in hybrid key establishment, which combines a classical method, such as Diffie-Hellman, with a post-quantum method. A secure construction combines their shared secrets so that the resulting key remains secret if at least one method resists attack. Here, hybrid refers to combining key-establishment methods. A hybrid cryptosystem can use hybrid key establishment as well.

Long-Term, Ephemeral, and Session Keys

A hybrid system using signatures and fresh Diffie-Hellman values has keys with three different lifetimes:

• A long-term key authenticates a party across many connections. In this construction, it is a signing key. Its lifetime is not dependent on the lifetime of any one session.

• An ephemeral key is a key-agreement value used for a single handshake. The Diffie-Hellman private values \(a\) and \(b\) are ephemeral keys when they are chosen fresh for each connection. They are used only to compute the shared secret and are erased once the handshake has computed it. They never encrypt data.

• A session key is derived from that shared secret and protects the data for the rest of the connection.

Ephemeral keys are the inputs to the key exchange, and session keys are its outputs. A protocol can create session keys without using ephemeral keys. RSA key transport and Kerberos both do, but the secret behind each session key is protected by a long-term key, so a later compromise of that long-term key exposes it.

Forward Secrecy

Ephemeral Diffie-Hellman provides a protection missing from RSA key transport using a long-term key. Forward secrecy (often called perfect forward secrecy) ensures that compromising a long-term key does not expose sessions recorded before the compromise.

An adversary who later steals a server’s private key can forge signatures from that point on and impersonate the server in new connections. It cannot decrypt a recorded session, because the session key came from \(g^{ab}\), and \(a\) and \(b\) were erased after the handshake. The recording contains only \(g^a\) and \(g^b\), and there is no known efficient way to recover the secret from those. Had Lavabit’s connections used ephemeral Diffie-Hellman, the key the FBI demanded would not have exposed anything already recorded.

Forward secrecy requires erasing the ephemeral private values and obsolete session secrets. If a party reuses the same Diffie-Hellman private value across connections, stealing that value exposes every recorded session that used it. Forward secrecy depends on erasing fresh values, not on Diffie-Hellman alone.

Forward secrecy does not protect against an attacker who can solve the underlying mathematical problem. A large enough quantum computer could recover the secret from recorded Diffie-Hellman values. Protecting traffic against that possibility requires post-quantum key establishment, such as a hybrid exchange combining classical and post-quantum methods.

TLS

In 1994, web traffic crossed the Internet unencrypted. Anything a user typed into a form, including a credit card number, could be read or altered by anyone on the path between the browser and the server. Netscape Communications, which made the most widely used web browser of the time, designed the Secure Sockets Layer (SSL) protocol to make buying things on the web safe enough to be practical. Its first version was never released because of design flaws. SSL 2.0 shipped in 1995, and SSL 3.0, a redesign, followed in 1996.

The name describes the design. Network programs send and receive data through sockets, the operating system’s interface to a TCP connection. SSL sits between the application and TCP and offers the same kind of interface. A program opens a connection and then reads and writes a stream of bytes. Underneath, SSL authenticates the server, divides the stream in each direction into chunks called records, encrypts each record, and detects any tampering with it. An application gains these protections by replacing its socket calls with SSL’s equivalents, without changing its own protocol. In the OpenSSL library, for example, SSL_read and SSL_write take the place of read and write. HTTP running over SSL became HTTPS, served on port 443 instead of port 80.

The Internet Engineering Task Force (IETF), which develops Internet protocol standards, took over the protocol and published it as Transport Layer Security (TLS) 1.0 in 1999. TLS 1.0 differed only slightly from SSL 3.0, and the version number inside its messages is 3.1. TLS now protects HTTPS and many other services, including email transfer between mail servers. The current version, TLS 1.3, was published in August 2018.

A typical HTTPS connection uses TLS to perform four jobs:

1. The client and server agree on which algorithms to use.

2. The client authenticates the server.

3. The two sides establish a fresh shared key.

4. Every record sent afterward, in either direction, is protected against reading and tampering.

The handshake is the part of the protocol that does the first three.

The TLS 1.3 Handshake

In a full handshake using a certificate and Diffie-Hellman, the client can normally send application data after one round trip. The main steps are:

1. ClientHello. The client sends a random value, supported versions and algorithms, and one or more ephemeral Diffie-Hellman public values. If none suits the server, the server can request another, adding a round trip.

2. ServerHello. The server selects the algorithms and sends its random value and its own ephemeral Diffie-Hellman public value. Both sides compute the shared secret and derive keys that encrypt the rest of the handshake.

3. Certificate and CertificateVerify. After sending additional connection settings, the server sends its certificate chain and a signature. The signed data includes a transcript hash, a hash of the handshake messages so far, and a label identifying the signature’s purpose.

4. Finished. The server sends an HMAC over the transcript, computed with a key derived from the handshake secret.

5. The client checks the certificate chain and domain name, verifies the signature and HMAC, and sends its own Finished message. Application data is then sent in records, each protected with separately derived keys and authenticated encryption with associated data (AEAD), which provides confidentiality and detects tampering.

The components come from the integrity primitives and the key exchange described earlier:

Fresh random values and Diffie-Hellman values make a new handshake’s transcript differ from a recorded one. Replaying the old signature or Finished message therefore fails verification.

Signing the Transcript

The server’s signature covers the handshake transcript up through its certificate, including both Diffie-Hellman values and the negotiated algorithms. This ties the verified identity to the current connection.

An adversary in the middle who substitutes its own Diffie-Hellman value changes the transcript. The server’s signature covers the transcript the server saw, which is not the one the client saw, so the client’s verification fails. An adversary cannot produce a new signature without the server’s private key.

This also detects attempts to edit the client’s list of supported versions or algorithms, one form of downgrade attack. Earlier TLS versions authenticated the transcript with Finished messages too, but weaknesses elsewhere could undermine that protection. The 2015 Logjam attack exploited weak export-grade Diffie-Hellman and a signature that did not cover the selected cipher suite. Recovering the weak shared secret let the attacker forge the Finished checks.

TLS 1.3 removed RSA key transport and Diffie-Hellman with reused private values. Certificate-based handshakes use ephemeral key agreement and provide forward secrecy.

Replayed Early Data

A client reconnecting to a server it visited recently can skip the certificate and signature by using a secret saved from the earlier connection. TLS 1.3 also lets such a client send application data in its very first message, before the server replies. This 0-RTT (zero round-trip time) data saves a round trip, but it gives up freshness. The server has not yet contributed a random value, so an attacker who records that first message can send it again. Applications should accept early data only when replaying it is harmless, such as a request that only reads a page, and reject it for anything that changes state, such as a payment. TLS itself cannot tell which requests are safe. Early data also lacks forward secrecy, because its keys come from the secret saved from the earlier connection rather than from a fresh Diffie-Hellman exchange.

What TLS Leaves to the Application

An ordinary HTTPS handshake authenticates the server, but it does not identify the user operating the browser.

TLS can authenticate the client with a certificate as well. Mutual TLS (mTLS) is used between services, where an organization can issue certificates to both ends. Public websites usually authenticate the user separately, inside the protected channel, with a password, passkey, or another login method.

Next: Part 4: Passwords

Lecture 4: Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Appendix
Lecture 4 Study Guide | List of terms