Le prechiavi risolvono un problema di sincronizzazione nell’avvio di una sessione. Non sostituiscono un canale di comunicazione né una gestione delle chiavi ben documentata.
Un destinatario offline può ricevere un messaggio cifrato in seguito perché il suo dispositivo ha pubblicato in anticipo materiale di chiave pubblica. Il mittente ha comunque bisogno di un servizio di consegna raggiungibile; «crittografia asincrona» non significa che i messaggi attraversino un’interruzione di rete o compaiano istantaneamente su un telefono disconnesso.
I progetti post-quantistici estendono questa idea con un meccanismo di incapsulamento delle chiavi. Le domande importanti riguardano come viene stabilito il segreto iniziale, come vengono ritirate le vecchie chiavi private e come i messaggi successivi rinnovano la sicurezza.
Le prechiavi risolvono un problema di sincronizzazione
Immagina che Maya sia offline quando Sam inizia una nuova conversazione. Il dispositivo di Maya ha precedentemente caricato prechiavi pubbliche. Sam può recuperare quel materiale, eseguire la parte dell’accordo sulle chiavi che compete al mittente e inviare un primo messaggio cifrato. Maya lo elabora dopo essersi riconnessa, usando chiavi private conservate sul proprio dispositivo.
Il server fornisce quindi informazioni pubbliche e accoda dati cifrati; non deve possedere il segreto risultante per i messaggi. La specifica X3DH di Signal è una descrizione primaria di questo modello asincrono. Una prechiave firmata e una prechiave monouso hanno durate e ruoli diversi; «prechiave» non significa una password segreta caricata sul server.
Per una conversazione già avviata, l’app può usare lo stato di sessione esistente anziché ripetere la configurazione iniziale per ogni messaggio. Avviare una sessione e far evolvere le sue chiavi dei messaggi sono operazioni separate.
Che cosa aggiunge un KEM post-quantistico
Un meccanismo di incapsulamento delle chiavi ha tre operazioni fondamentali: generare le chiavi, incapsulare usando una chiave pubblica e decapsulare usando la corrispondente chiave privata. L’incapsulamento produce sia un segreto condiviso sia un testo cifrato. Il testo cifrato può essere consegnato in seguito; il segreto stesso non viene inviato in chiaro.
NIST FIPS 203 standardizza ML-KEM. Per ML-KEM-768, la chiave pubblica di incapsulamento misura 1.184 byte, il testo cifrato 1.088 byte e il segreto condiviso 32 byte. Sono dimensioni a livello di algoritmo, non quelle di un intero pacchetto di messaggistica. Firme, chiavi classiche, identificatori e struttura del trasporto aggiungono overhead; una chiave pubblica in cache potrebbe non accompagnare ogni messaggio.
In una costruzione ibrida, un protocollo combina materiale segreto classico e post-quantistico secondo uno schema definito di derivazione delle chiavi. Accostare nomi di algoritmi non dimostra che la composizione sia sicura. Il legame con le identità, la validazione, la separazione dei domini e la gestione degli errori richiedono specifiche e revisione.
Un esempio: PQXDH, non un modello universale
La specifica PQXDH di Signal descrive prechiavi post-quantistiche monouso firmate e una chiave firmata di ultima risorsa. Il mittente verifica le firme fornite, esegue l’accordo sulle chiavi e include il testo cifrato del KEM e gli identificatori delle chiavi nel primo messaggio cifrato. In seguito, il destinatario deriva lo stesso segreto ed elabora il messaggio.
La chiave di ultima risorsa consente l’avvio quando non sono disponibili chiavi KEM monouso, ma l’analisi in caso di compromissione non è identica. Eliminazione e rotazione delle chiavi private influiscono sulla protezione delle sessioni precedenti. La specifica distingue inoltre la segretezza in avanti post-quantistica dall’autenticazione contro un attaccante quantistico attivo. Questi dettagli non devono essere sostituiti con «il ripiego non ha alcun costo in termini di sicurezza».
PQXDH è una costruzione specificata precisa. Le sue esatte curve, firme e scelte di parametri non devono essere copiate nella descrizione di un altro prodotto, a meno che quest’ultimo le documenti.
Un ratchet non è una riserva di prechiavi
Le prechiavi supportano l’avvio della sessione. Un protocollo ratchet cambia i segreti durante la conversazione. La specifica Double Ratchet spiega l’evoluzione delle chiavi dei messaggi e costruzioni ratchet post-quantistiche più recenti, compresi progetti che non trasmettono un intero scambio post-quantistico con ogni messaggio applicativo.
La segretezza in avanti riguarda i messaggi precedenti dopo una successiva compromissione delle chiavi. La sicurezza post-compromissione riguarda il recupero della sicurezza delle comunicazioni future dopo che l’attaccante perde l’accesso e viene incorporato nuovo materiale segreto. Nessuna delle due significa che il malware possa rimanere su un telefono indefinitamente mentre la crittografia gli nasconde in qualche modo il testo in chiaro di quel telefono.
Eliminare una prechiave pubblica dal server ne impedisce il normale riutilizzo; non equivale a eliminare la corrispondente chiave privata da un endpoint. Un audit utile verifica sia le regole del ciclo di vita sia il comportamento con i messaggi in ritardo.
Che cosa documenta Livara e che cosa richiede ancora prove
La pagina sulla sicurezza di Livara descrive l’avvio ibrido delle sessioni con chiavi monouso quando disponibili, i normali avanzamenti della catena dei messaggi e periodiche epoche ML-KEM. Questo differisce dalla vecchia affermazione secondo cui ogni messaggio esegue un nuovo scambio ML-KEM completo. Sono dichiarazioni della documentazione del prodotto, non una verifica indipendente dell’implementazione.
Non dedurre da queste dichiarazioni una specifica politica di ripiego quando le chiavi sono esaurite, un intervallo di rifornimento o un valore di latenza di rete. Queste domande richiedono documentazione del protocollo specifica per la versione o risultati misurati. Anche il Proof Lab non è un test completo dell’avvio asincrono, dell’esaurimento delle chiavi o del recupero dei messaggi in ritardo.
Come valutare le affermazioni sulla messaggistica offline
Chiedi al fornitore o al revisore prove che coprano questi casi:
| Caso di test | Che cosa osservare |
|---|---|
| Primo messaggio a un contatto disconnesso | Quale materiale di chiave pubblica è stato usato e quando il destinatario riceve effettivamente il messaggio |
| Prechiavi monouso esaurite | Se l’avvio si arresta o segue un ripiego documentato e quale compromesso di sicurezza viene dichiarato |
| Il destinatario reinstalla o cambia identità | Se i vecchi messaggi in coda rimangono decifrabili e se i cambiamenti delle chiavi sono visibili |
| Messaggi ritardati o riordinati | Limiti di conservazione, gestione delle chiavi saltate ed errori comprensibili |
| Ritorno dopo una lunga assenza | Rinnovo sicuro delle chiavi, elaborazione limitata e stato di consegna accurato |
| Confronto delle prestazioni | Dispositivo, versione dell’app, rete, dimensione del payload e misure separate per avvio iniziale e sessioni già stabilite |
Usa account e messaggi di test privi di informazioni sensibili. Una prova di consegna riuscita dimostra quello scenario, non ogni proprietà crittografica. Viceversa, una consegna fallita può dipendere dalla rete o dal ciclo di vita anziché da una violazione del cifrario.
Domande frequenti
Il destinatario può essere offline mentre invio?
Sì, se l’applicazione dispone del materiale pubblico necessario e dell’infrastruttura di consegna e archiviazione. Il destinatario non può leggere il messaggio in coda finché il suo dispositivo non riesce a recuperarlo ed elaborarlo.
Chiavi KEM più grandi rendono sempre le chat sensibilmente più lente?
Dalla sola dimensione delle chiavi non segue alcuna affermazione universale sui tempi. Contano frequenza di avvio, raggruppamento, cache, implementazione e condizioni di rete. Pubblica un benchmark invece di promettere overhead nullo.
Una prechiave firmata prova chi è la persona dietro l’account?
Autentica il materiale rispetto a un’identità di firma. Come tale identità venga legata alla persona che intendi contattare è una questione distinta di fiducia e verifica.
La crittografia post-quantistica funziona senza alcuna connessione?
Alcuni calcoli locali possono essere eseguiti offline. La consegna dei messaggi richiede comunque un percorso di comunicazione; la crittografia non ne fornisce uno.
