Forward secrecy limits what a later key theft reveals

A certificate signing key authenticates the handshake; an ephemeral private value participates in establishing a fresh agreement secret. Traffic secrets and derived record keys then protect particular directions and generations of data. In the stated certificate-authenticated ephemeral mode, learning the signing key afterward does not by itself reconstruct the erased agreement secret from public handshake values, assuming the negotiated cryptography remains hard. This distinction is the reason reusing the certificate key across many connections need not make all recorded connections decryptable after its later theft.

The conclusion depends on secret generation, lifetime, and compromise scope. Reusing ephemeral private values, retaining session secrets in crash dumps, enabling key logging, or leaving plaintext in accessible storage can defeat the intended boundary. Erasing a secret is also an implementation and operational claim, not something proved by the presence of an ephemeral key-share extension. Inspect the negotiated mode and the material actually retained. The lesson does not claim protection against an adversary present at the endpoint while the data is processed.

TLS 1.3 permits resumption using a pre-shared key with fresh ephemeral agreement or using that PSK without a fresh agreement contribution. Those modes have different forward-secrecy properties with respect to later PSK compromise. Early data is derived before the server contributes a fresh key share for that connection, so it lacks the full forward-secrecy property of ordinary fresh-agreement application traffic. Saying that a connection negotiated TLS 1.3 is therefore insufficient to characterize every byte's protection.

Ticket-encryption keys, stored resumption PSKs, and application session tokens are separate credentials with separate lifetimes. A long-lived ticket-protection key can expand the consequences of collecting old tickets, depending on how state is encoded and retained. Do not assume that rotating a certificate also rotates all resumption material. Document which key compromise the analysis considers and whether the affected data was early data, ordinary traffic, or plaintext retained beyond TLS. A precise incident timeline is more useful than an unqualified claim of perfect secrecy.

A TLS KeyUpdate derives the next traffic secret from the current one. If an attacker knows the current secret, the same public derivation lets it follow future updates on that connection. Updating repeatedly therefore does not remove that knowledge. Recovering from such exposure requires a clean endpoint and an appropriate fresh establishment of secrets; continuing with a compromised implementation or stolen resumption material can invalidate the hoped-for recovery. Historical plaintext already observed cannot be made secret again by any later rotation.

Use the probability lab for an audit-sampling question about retained secrets, not a cryptographic-strength estimate. Suppose independently selected completed-session artifacts have a synthetic 0.2 probability of still containing disallowed secret material. Reset, set both p=0.2 and n=10, predict the zero-detection bar, then inspect it with Play or Step. The binomial model does not inspect memory, derive keys, or validate erasure. Shared dump configuration can correlate artifacts, so the actual audit must test the retention mechanism and its exceptional paths.