L’avanzamento della catena per messaggio e il rinnovo di un’epoca post-quantistica risolvono parti diverse del problema del ratchet.
Un ratchet ibrido post-quantistico aggiorna le chiavi di messaggistica usando materiale sia classico sia post-quantistico. L’obiettivo è conservare la protezione, sotto ipotesi definite con attenzione, se un componente diventa vulnerabile, limitando nel tempo i danni di determinate compromissioni delle chiavi.
Livara documenta questo approccio per LVR1 usando P-256 e ML-KEM-768. Comprendere il progetto richiede di distinguere l’instaurazione iniziale delle chiavi, i normali aggiornamenti della catena dei messaggi e i rinnovi post-quantistici periodici. Non sono la stessa operazione eseguita per ogni messaggio.
Da un segreto condiviso a chiavi dei messaggi che cambiano
Un meccanismo di instaurazione delle chiavi fornisce ai partecipanti materiale segreto utilizzabile in uno schema di derivazione delle chiavi. Un protocollo ratchet fa poi evolvere lo stato e deriva le chiavi dei messaggi, invece di conservare una sola chiave di contenuto invariata per l’intera conversazione.
NIST FIPS 203 specifica ML-KEM, incluso il set di parametri ML-KEM-768. Stabilisce un segreto condiviso; un cifrario autenticato come AES-GCM cifra il payload del messaggio. L’autenticazione e il modo in cui i componenti vengono combinati appartengono al protocollo più ampio.
La panoramica sulla sicurezza di Livara descrive un’instaurazione ibrida, radici classiche e post-quantistiche indipendenti, catene unidirezionali di invio e ricezione che avanzano con i messaggi e aggiornamenti periodici delle epoche ML-KEM. Afferma che una chiave di messaggio viene combinata con la radice post-quantistica corrente prima della protezione del contenuto e dell’intestazione.
Questa descrizione non va riscritta come «per ogni messaggio avvengono un nuovo scambio P-256 e un nuovo incapsulamento ML-KEM». Un avanzamento della catena può essere un passaggio di derivazione delle chiavi relativamente poco costoso.
Che cosa cambia un’epoca
Un’epoca è un periodo dello stato del protocollo associato a uno specifico rinnovo. Distribuire tra le epoche i messaggi più grandi di instaurazione delle chiavi può ridurre il sovraccarico ripetuto di comunicazione, ma rende anche le regole di rinnovo rilevanti per la sicurezza.
Chi esamina il progetto dovrebbe chiedere:
- Che cosa attiva una nuova epoca: un contatore, il tempo, un’azione dell’interlocutore o un’altra condizione?
- Come vengono autenticati gli identificatori delle epoche e il materiale delle chiavi?
- Che cosa succede ai messaggi in ritardo, duplicati o fuori ordine?
- Come gestisce un client un aggiornamento mancante o un interlocutore più vecchio e incompatibile?
- Quali vecchi segreti vengono conservati per la consegna ritardata e quando vengono eliminati?
Un’implementazione richiede risposte precise. La parola «periodico» da sola non è una specifica completa di recupero o interoperabilità.
Quantificare le dimensioni delle primitive senza inventare un benchmark
FIPS 203 assegna a ML-KEM-768 una chiave di incapsulamento di 1.184 byte e un testo cifrato di 1.088 byte. Sono codifiche delle primitive, non le dimensioni complessive di un messaggio o di un handshake Livara. Intestazioni del protocollo, firme, framing e frequenza di invio di ciascun valore determinano il traffico effettivo.
Anche le dimensioni delle chiavi P-256 dipendono dalla rappresentazione. Per esempio, un punto di curva compresso e uno non compresso hanno lunghezze codificate diverse. Confrontare una «dimensione della chiave P-256» non meglio definita con un testo cifrato ML-KEM non è un’analisi completa della larghezza di banda.
Per valutare il costo di un ratchet, misurate byte per conversazione ed epoca, tempo CPU, memoria, risvegli della radio e latenza end-to-end su dispositivi rappresentativi. Indicate le condizioni della build e della rete. Senza tali misure, non sono giustificati né un «impatto trascurabile sulla batteria» né un tempo di esecuzione universalmente inferiore al millisecondo.
Segretezza in avanti e recupero dopo una compromissione
La segretezza in avanti mira a proteggere i messaggi precedenti dopo l’esposizione di determinati segreti successivi, a condizione che i vecchi segreti necessari siano stati cancellati. La sicurezza post-compromissione riguarda il recupero della protezione quando un attaccante non controlla più il dispositivo terminale e nel protocollo entra nuovo materiale segreto a lui sconosciuto.
La specifica Double Ratchet spiega queste distinzioni e i limiti del recupero dopo un’intrusione. L’accesso continuato del malware, la casualità manipolata o un attaccante attivo che controlla gli scambi pertinenti possono impedire il recupero sperato. Inviare un altro messaggio non dimostra che una sessione rubata sia stata revocata o che un telefono compromesso sia pulito.
Una costruzione ibrida richiede anche autenticazione e combinazione solide. «L’attaccante deve violare entrambi gli algoritmi» è una proprietà perseguita sotto le ipotesi della costruzione, non un’affermazione incondizionata che copra bug di implementazione o terminali malevoli.
Mantenere visibili i confini delle funzionalità
Nella documentazione di Livara, le chiavi mittente dei gruppi LGS1 vengono distribuite tramite sessioni LVR1 tra coppie di partecipanti. Ciò non significa che una catena mittente di gruppo sia strutturalmente identica al Double Ratchet di una chat diretta. L’attuale pagina sulla sicurezza esclude inoltre dalla E2EE i gruppi più vecchi incompatibili e richiede che i membri siano pronti prima di creare un nuovo gruppo cifrato.
Gli allegati hanno proprie chiavi di contenuto, trasportate all’interno della conversazione protetta. Le chiamate e la registrazione facoltativa sul server richiedono un esame separato; non deducete una protezione post-quantistica dei media solo perché un percorso di segnalazione usa una sessione ibrida. I canali pubblici e i metadati operativi non rientrano nella riservatezza dei contenuti privati.
Che cosa rafforzerebbe la fiducia?
Cercate una specifica versionata, test di interoperabilità e dei casi di errore, una revisione indipendente e una relazione chiara tra il codice sorgente esaminato e il client distribuito. Gli algoritmi standard forniscono elementi utili sui componenti, non una certificazione della loro composizione.
Il Proof Lab di Livara dimostra primitive classiche selezionate ed esclude esplicitamente la composizione completa LVR1/LGS1 da quel banco di prova locale. Il suo modello di minaccia resta un contesto necessario. Insieme, questi materiali aiutano a formulare domande; non devono essere presentati come sostituti di una valutazione completa del protocollo e dell’implementazione.
