sitzungsschluessel

Session Key

In short: A temporary symmetric key that’s only valid for the duration of a single connection (session) and is discarded afterwards.

In more detail: Session keys are the core of a hybrid encryption scheme: during the handshake, the session key is securely exchanged asymmetrically, and the actual payload data of the connection is then quickly encrypted symmetrically with this key. A new session key per connection ensures that even if a key is compromised, only that one session is affected, not all past or future connections (forward secrecy).

In Depth

The process can be roughly sketched like this:

1. Client and server agree on a session key during the handshake
   (exchanged/derived asymmetrically, e.g. via Diffie-Hellman)
2. All payload data of the connection is en-/decrypted symmetrically
   with this one key (fast, e.g. with AES)
3. Connection ends -> session key is discarded
4. New connection -> new, completely independent session key

The reason for this two-stage approach is pure performance: asymmetric encryption (with a permanent key pair) is considerably more computationally expensive than symmetric — encrypting every single transmitted byte asymmetrically would be far too slow for the data volumes of a normal web connection. The session key therefore combines the advantages of both worlds: exchanged securely asymmetrically, but used quickly symmetrically.

Particularly important is the “forward secrecy” that modern TLS connections provide through session keys: if a server’s long-term private key is compromised years later (e.g. stolen), an attacker still CANNOT use it to retroactively decrypt old, long-finished sessions — for that they’d need the session key from back then, which was never stored anywhere permanently and has long since been discarded. Without forward secrecy (older TLS versions), an attacker could store recorded, encrypted traffic and decrypt it retroactively years later, as soon as they get hold of the long-term key.

Diffie-Hellman as a derivation mechanism

In modern TLS connections, the session key is usually derived via a Diffie-Hellman key exchange (more precisely: Elliptic Curve Diffie-Hellman Ephemeral, ECDHE), instead of being directly transmitted asymmetrically encrypted. The principle is mathematically elegant: both sides each generate a temporary, random key pair, exchange only their public parts, and can each INDEPENDENTLY compute the same shared value from that — an eavesdropper listening to both public parts can’t practically compute this shared value themselves from the intercepted data (the underlying mathematical problem, the discrete logarithm, is considered practically unsolvable). The “E” for “ephemeral” (temporary) is crucial here for forward secrecy: because a fresh, temporary key pair is generated for EVERY new connection and then discarded, there’s no permanently stored secret value at all that an attacker could later steal to decrypt old sessions.

Session resumption as a compromise

Because a full handshake with new key negotiation costs computing time and additional network round trips, modern TLS versions support “session resumption”: when reconnecting to the same server shortly after the last session, an abbreviated handshake can be used that builds on previously negotiated material, instead of negotiating completely from scratch — this noticeably speeds up repeated connections (e.g. when reloading the same website), without undermining the fundamental security of the session-key concept, as long as the underlying expiry times and renewal intervals are configured correctly.

Session keys beyond TLS

The concept isn’t limited to web connections: SSH also uses a negotiated session key when establishing a connection for the actual encrypted transmission, independent of the server’s permanent host key or the user’s personal keys. VPN protocols like WireGuard or IPsec follow the same basic principle: an initial, asymmetrically secured negotiation phase, followed by fast symmetric encryption with a temporary session key for all further traffic. The pattern “negotiate asymmetrically, transmit symmetrically” thus appears practically everywhere two parties need to establish an encrypted connection without a previously existing secure channel.

See also: Hybrid key schemes, Handshake, Symmetric encryption