Non sono completamente sicuro di aver capito il concetto. Ma penso che il punto sia quello con chiavi asimmetriche a breve termine ("effimere") (DH, ECDH al giorno d'oggi. Ma "l'RSA effimero" era anche una cosa.) Ci sono diverse opinioni su esattamente quanto a breve termine si suppone che queste chiavi siano.
All'alta paranoia "a breve termine" potrebbe significare "una volta per ogni connessione". E alla paranoia bassa, la parola "breve termine" potrebbe significare "fino a quando non si reinstalla il software perché le condivisioni di chiavi vengono sempre generate solo durante l'installazione" . - E tutto in mezzo. Ad esempio con F5 penso che l'impostazione predefinita sia di rigenerare le chiavi DH una volta all'ora. Ma puoi opzionalmente impostare il parametro "uso singolo DH" per rigenerare effettivamente per ogni connessione. E OpenSSL ha un'opzione chiamata "SSL_OP_SINGLE_DH_USE" che, penso, fa la stessa cosa. E altrimenti i tasti DH vengono rigenerati solo al riavvio del server. E con Citrix NetScaler puoi definire un numero massimo di connessioni dopo il quale i tasti DH vengono rigenerati.
(Vedi una risposta mia correlata .)
Non penso che le specifiche TLS abbiano mai specificato quanto spesso si debba rigenerare chiavi effimere. Penso che lascino questo fino all'implementatore completamente e non facciano mai un commento esplicito o persino implicito.
Ora, cosa significa questo senso di sicurezza? Supponiamo che tu abbia una connessione TLS. Con il caso migliore - uso singolo DH - da un lato. E un caso non così buono - la rigenerazione delle chiavi DH al riavvio del server - dall'altra parte. E supponiamo di avere un uomo nel mezzo dell'attaccante che sta impiegando un attacco "prendi tutto". E registra solo il traffico crittografato per alcune settimane.
Ora se quell'attaccante in qualche modo ottiene un compromesso non completo di una delle estremità della connessione - come per es. un'istantanea con RAM di una di queste estremità: che cosa gli dà?
Se è abbastanza fortunato da ottenere l'istantanea della fine non-così-buona di quanto ciò consentirebbe a quell'attaccante di decrittografare retroattivamente tutte le connessioni protette passate DHE passate dal passato. Dopo il riavvio del server. E anche INTO THE FUTURE fino a al prossimo riavvio.
E non importa se tutti gli altri fini cambiano costantemente la loro parte nell'effimero ballo chiave.
Spero che questo in qualche modo risponda alla tua domanda.
Nota a margine: c'era in realtà qualche DOMANDA per client / server TLS che NON hanno effettivamente molta effimera (è una parola?) per le loro chiavi effimere durante il processo di progettazione di TLS 1.3: link