Il progresso utile è un nuovo strumento per la riservatezza a lungo termine. Il suo valore dipende da integrazione, implementazione e limiti operativi.
ML-KEM-768 aiuta due parti a stabilire un segreto condiviso che può poi essere usato per proteggere i messaggi. È un componente di un sistema di messaggistica, non un protocollo di chat completo, un cifrario per i messaggi o un certificato che un’app sia sicura.
Il NIST ha pubblicato FIPS 203 il 13 agosto 2024, standardizzando ML-KEM e i suoi insiemi di parametri 512, 768 e 1024. La loro sicurezza si basa su problemi reticolari ritenuti resistenti agli attacchi quantistici. «Ritenuti resistenti» è un’ipotesi di sicurezza sostenuta dall’analisi, non una promessa che non siano possibili debolezze future. NIST FIPS 203.
Dove si colloca un KEM in una chat cifrata
Un modo utile per leggere una dichiarazione sulla crittografia è seguire il materiale delle chiavi:
- Autenticare l’interlocutore previsto. Uno scambio di chiavi con un impostore rimane uno scambio con la persona sbagliata.
- Stabilire materiale segreto condiviso. Un KEM contribuisce un segreto mediante incapsulamento e decapsulamento.
- Derivare chiavi per i rispettivi scopi. Una funzione di derivazione delle chiavi separa il materiale usato dalle diverse parti del protocollo.
- Cifrare e autenticare i messaggi. Uno schema di cifratura autenticata protegge i contenuti e rileva modifiche non autorizzate.
- Gestire la sessione nel tempo. Rotazione ed eliminazione delle chiavi, cambi di dispositivo e recupero determinano che cosa una compromissione successiva può esporre.
Questi passaggi spiegano perché uno standard per il secondo passaggio non può convalidare l’intera applicazione. Le FAQ post-quantistiche del NIST offrono contesto per l’adozione dei nuovi standard.
Perché combinare ML-KEM con un accordo classico sulle chiavi?
Un progetto ibrido usa una componente post-quantistica insieme a una classica, come Diffie–Hellman su curve ellittiche. Il beneficio previsto è evitare di dipendere esclusivamente da uno dei due insiemi di ipotesi durante una transizione.
L’affermazione di sicurezza riguarda il combinatore e il protocollo completi, non semplicemente un elenco di due algoritmi. I revisori devono sapere quali input vengono autenticati, come vengono codificati e combinati, quale contesto viene legato alla derivazione e che cosa accade quando una componente fallisce. Concatenare segreti senza una costruzione specificata non è un argomento di sicurezza.
Per gli utenti, la domanda pratica non è «La pagina delle impostazioni dice resistente ai quanti?», ma «Quali conversazioni e versioni usano davvero questa costruzione, e quali prove sostengono tale affermazione?».
Che cosa documenta Livara
La documentazione sulla sicurezza di Livara descrive sessioni LVR1 di chat diretta che usano materiale classico P-256 e ML-KEM-768, con AES-256-GCM per i contenuti. Descrive i gruppi privati LGS1 come catene del mittente distribuite tramite sessioni LVR1 a coppie. Sono livelli diversi: un normale messaggio di gruppo non è necessariamente un nuovo scambio ML-KEM per ogni destinatario.
Leggi tale documentazione come la descrizione dello sviluppatore. Nominare primitive standardizzate non dimostra che la composizione personalizzata di Livara sia stata sottoposta a un audit indipendente o che ogni build installata la implementi correttamente. Il Proof Lab limita esplicitamente la propria dimostrazione nel browser: non esegue i ratchet LVR1/LGS1 completi e non costituisce un audit del protocollo.
Che cosa non copre la protezione post-quantistica
| Domanda | Perché ML-KEM da solo non risponde |
|---|---|
| Un destinatario può copiare il mio messaggio? | Il destinatario riceve contenuti leggibili. |
| Il mio dispositivo è privo di spyware? | L’integrità dell’endpoint è un’ipotesi di fiducia separata. |
| I backup sono protetti? | Le chiavi dei backup e le regole di recupero richiedono un progetto proprio. |
| I cambiamenti dei membri del gruppo sono sicuri? | Contano le regole di autenticazione, appartenenza e rinnovo delle chiavi. |
| Il servizio conserva metadati? | La cifratura dei contenuti non nasconde automaticamente instradamento o tempi. |
| Una chiamata è protetta come una chat testuale? | Segnalazione e flussi multimediali delle chiamate possono usare protocolli diversi. |
Il modello di minaccia di Livara distingue inoltre le conversazioni private dai canali pubblici e riconosce l’esposizione a livello di dispositivo. Non estendere un’affermazione sulle chat dirette a ogni ambito del prodotto.
Una checklist per chi acquista «messaggistica FIPS 203»
Chiedi l’esatto insieme di parametri e la versione del protocollo; una descrizione dell’autenticazione dell’interlocutore e della combinazione delle chiavi; le versioni client supportate; il comportamento con client incompatibili; e test o risultati di revisione legati all’implementazione distribuita. Se un fornitore dichiara una convalida FIPS, chiedi il relativo documento di convalida e il suo ambito. Usare un algoritmo descritto in una pubblicazione FIPS non dimostra, da solo, la convalida del prodotto o del modulo.
Non dedurre autonomia, throughput o reattività dell’app dal nome del parametro. Servono misurazioni con dispositivo, build e carico di lavoro documentati.
Il cambiamento utile per la messaggistica è un nuovo strumento per la riservatezza a lungo termine. Il suo valore dipende da integrazione, implementazione e limiti operativi, non dal sostituire un’etichetta di marketing con un’altra.
