---
{
  "title": "Key agreement",
  "summary": "Establish a shared secret without sending that secret as plain data.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "IETF: TLS 1.3 specification",
      "url": "https://www.rfc-editor.org/rfc/rfc8446.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Key agreement lets parties derive shared key material through a defined exchange. Diffie–Hellman and elliptic-curve variants are important examples. An unauthenticated exchange may establish a secret with an attacker acting as an intermediary, so authentication is an essential part of a secure protocol. Ephemeral exchanges can support forward secrecy, limiting what later exposure of a long-term key reveals about earlier communications.

## In practice

During a TLS connection, the parties negotiate an exchange and derive traffic keys. Certificate-based authentication helps establish the server’s identity.

## A common misunderstanding

Key agreement alone does not tell you whom you are communicating with.

## Check your understanding

Why combine key agreement with authentication?

**Think it through:** To prevent a substituted peer from establishing its own secure-looking connection with each participant.

## Establishing a secret does not name the peer

A fictional browser and service perform an ephemeral exchange to derive shared key material. An observer should not learn the resulting secret merely from the public exchange under the protocol's assumptions. However, without authentication, an intermediary might establish a separate exchange with each side. Each side would have a secret, but not necessarily with the intended peer.

A complete protocol binds the exchange to identity and to the relevant conversation. It also derives traffic keys with defined purposes rather than using raw shared material indiscriminately. Negotiated algorithms, transcript handling, and failure behavior belong to the protocol specification and should be implemented through maintained libraries.

Forward secrecy concerns what later exposure of a long-term secret reveals about earlier protected conversations. Appropriate ephemeral exchanges can support that property when the protocol and implementation meet their requirements. It does not mean endpoint compromise cannot expose current plaintext or that retained session keys are harmless.

## Label the secrets in a handshake

For a paper exercise, draw two intended peers and an intermediary. First show an unauthenticated exchange, then add the protocol's peer-authentication step. Explain which evidence lets one side reject a substituted peer. No real keys or live network interception are needed.

Identify long-term authentication keys separately from temporary exchange material and derived traffic keys. State which component creates, stores, and destroys each according to the supported protocol. This makes key compromise scenarios easier to reason about. A secure-looking encrypted connection is meaningful only when the parties have established both the required secret and the intended authenticated relationship, with explicit rules for deriving and using the resulting keys.

## Keep exploring

- [[tls]]
- [[ecc]]
- [[man-in-the-middle]]
- [[key-management]]