SHARE THE PERSPECTIVE
Il nome di un protocollo non dimostra la sicurezza: contano architettura, implementazione e comportamento reale quando cambiano membri e chiavi.

Messaging Layer Security (MLS) e LGS1 di Livara non sono due certificati intercambiabili di sicurezza delle chat di gruppo. MLS è uno standard di protocollo IETF; LGS1 è il progetto specifico di prodotto documentato da Livara. Un confronto corretto separa architettura, prove sull’implementazione e comportamento effettivamente sperimentato dagli utenti.

La distinzione fondamentale è tra uno stato di gruppo condiviso basato su un albero e chiavi del mittente distribuite tramite sessioni a coppie. Nessuna etichetta, da sola, indica se una particolare applicazione gestisca correttamente un membro rimosso, un dispositivo non aggiornato o una chiave compromessa.

La differenza architetturale

RFC 9420 specifica MLS per l’instaurazione asincrona delle chiavi di gruppo. Usa un albero ratchet ed epoche di gruppo, con segretezza in avanti e sicurezza post-compromissione a condizioni definite. La struttura ad albero riduce alcuni costi di aggiornamento delle chiavi all’aumentare delle dimensioni del gruppo.

La documentazione sulla sicurezza di Livara descrive LGS1 come una catena del mittente firmata per ogni membro, distribuita tramite sessioni LVR1 a coppie e rinnovata quando cambia la composizione del gruppo. È una dichiarazione sul prodotto, non una prova che LGS1 sia conforme a MLS o disponga della stessa analisi.

Domanda MLS Documentazione di Livara LGS1
Struttura condivisa Albero ratchet ed epoche Catene per mittente
Aggiornamenti delle chiavi Cambiamenti dello stato del gruppo consolidati in una nuova epoca Nuove chiavi del mittente distribuite ai membri
Stato della specifica Standard IETF, RFC9420 Descrizione pubblicata specifica del prodotto
Che cosa resta da valutare Integrazione applicativa e implementazione Specifica completa, implementazione e prove indipendenti

Questa tabella descrive categorie di progetto. Non è un benchmark né una classifica di sicurezza.

Che cosa significa «logaritmico» e che cosa non significa

Un aggiornamento crittografico può usare un numero logaritmico di componenti cifrati del percorso nell’albero senza rendere logaritmico tutto il lavoro del sistema. I messaggi devono comunque essere distribuiti, i client conservano stato e il comportamento dipende dalla struttura del gruppo e dalle operazioni. Il vecchio confronto «MLS richiede O(log N) messaggi mentre tutto in LGS1 è più veloce» mescolava costi diversi e non offriva misurazioni.

L’architettura MLS, RFC 9750, tratta il servizio di consegna separatamente dall’instaurazione crittografica delle chiavi. Discute la distribuzione dei messaggi e l’ordinamento dei cambiamenti del gruppo. Questa separazione conta: calcolo sul client, byte di un commit, distribuzione complessiva dal server e traffico di riconnessione sono metriche diverse.

Un rapporto significativo sulle prestazioni dovrebbe indicare:

  • dimensioni del gruppo e numero di dispositivi per persona;
  • se l’operazione è un messaggio normale, la rimozione di un membro, un aggiornamento delle chiavi o una riconnessione;
  • byte inviati dal client che avvia l’operazione rispetto al traffico totale di consegna;
  • tempo trascorso, modello del dispositivo, versione dell’implementazione e condizioni di rete;
  • costo degli aggiornamenti mancati e dei cambiamenti ripetuti dei membri.

Senza questi dettagli, affermazioni su «millisecondi», «basso overhead di stato» o superiorità a una certa dimensione del gruppo non sono dimostrate.

Rimuovere un membro è un test del ciclo di vita

Un amministratore che rimuove un account rappresenta solo una parte della questione. I client devono concordare sul nuovo stato dei membri, usare nuove chiavi adeguate ed evitare di fornirle ai dispositivi esclusi. Chi possiede già vecchio testo in chiaro o vecchie chiavi può conservare l’accesso ai contenuti precedenti; la rimozione non può far sparire le sue copie.

Per entrambi i sistemi, un test utile chiede: dopo il completamento della rimozione, il dispositivo escluso può decifrare un nuovo messaggio di prova non sensibile? Un membro che era offline può recuperare in sicurezza gli aggiornamenti? Vengono gestiti tutti i dispositivi appartenenti a un account? L’interfaccia rende visibili gli errori o i cambiamenti dei membri?

Sono domande di valutazione proposte, non risultati di test svolti qui. Un confronto tra prodotti dovrebbe pubblicare l’esito osservato e la versione testata, anziché equiparare un clic amministrativo riuscito all’esclusione crittografica.

Segretezza in avanti e recupero sono condizionali

Mantenere protetti i vecchi messaggi dopo una compromissione successiva dipende dal ritiro del vecchio materiale segreto. Recuperare la protezione dei messaggi futuri dipende dall’incorporazione di nuovi segreti dopo che l’attaccante perde l’accesso rilevante. In MLS, elaborare gli aggiornamenti del gruppo fa parte di questo recupero; inviare un aggiornamento non equivale al fatto che tutti i membri lo abbiano applicato. Consulta le considerazioni sulla sicurezza in RFC 9420.

Per un progetto basato su chiavi del mittente, chiedi come venga sostituito e ridistribuito lo stato compromesso di ciascun mittente. Una catena unidirezionale da sola non dovrebbe essere descritta come capace di riprendersi automaticamente da un attaccante che ne conosce lo stato attuale. La protezione a coppie usata durante la ridistribuzione è rilevante, ma non sostituisce un’analisi completa a livello di gruppo.

Le affermazioni post-quantistiche richiedono una suite crittografica e un ambito precisi

Le suite crittografiche definite nell’RFC9420 di base usano meccanismi classici a chiave pubblica. MLS è estensibile, quindi un’affermazione su una particolare implementazione dovrebbe identificarne la suite effettiva e le estensioni, anziché dichiarare che tutte le installazioni MLS rimarranno per sempre classiche.

L’uso documentato della distribuzione ibrida LVR1 da parte di LGS1 è un’affermazione diversa da una garanzia post-quantistica analizzata indipendentemente per ogni operazione del gruppo. FIPS 203 standardizza ML-KEM; non certifica l’intero protocollo di gruppo che lo incorpora. Valuta insieme autenticazione, cambiamenti dei membri, compromissione delle chiavi e implementazione, non soltanto il nome del KEM.

Che cosa chiedere prima di scegliere un prodotto

Chiedi la specifica attuale del protocollo, vettori di test e una revisione indipendente specifica della versione, compresi i rilievi irrisolti. Poi confronta i normali requisiti di prodotto: dispositivi supportati, comportamento degli aggiornamenti, recupero, ruoli di moderazione e dati conservati dai server.

L’architettura MLS considera esplicitamente i servizi applicativi e le loro ipotesi di fiducia. Analogamente, il modello di minaccia di Livara dovrebbe essere letto insieme alle dichiarazioni sul prodotto. La crittografia non rende affidabili i partecipanti autorizzati, non impedisce screenshot e non elimina ogni forma di metadati.

Se mancano prove, annota «non dimostrato» invece di etichettare automaticamente un progetto come insicuro o superiore. La decisione dovrebbe riflettere i rischi del tuo gruppo e la qualità delle prove disponibili.

Domande frequenti

LGS1 è un’implementazione di MLS?

Le descrizioni pubblicate mostrano architetture diverse. Questo articolo non identifica LGS1 come un’implementazione di MLS né afferma l’interoperabilità.

MLS richiede che tutti i membri siano online contemporaneamente?

No. L’uso asincrono fa parte del suo progetto. Le applicazioni hanno comunque bisogno di politiche per aggiornamenti ritardati, stato obsoleto e membri offline da molto tempo.

La distribuzione post-quantistica delle chiavi risolve la sicurezza del gruppo?

No. Affronta una parte dell’instaurazione delle chiavi. Identità, appartenenza al gruppo, ciclo di vita delle chiavi, sicurezza degli endpoint e implementazione richiedono ancora prove.

Quale progetto è più veloce?

Questo articolo non contiene un benchmark che stabilisca un vincitore. Misura le operazioni e l’ambiente d’uso che contano per il tuo gruppo.

Esplora il Proof Lab
CONTINUE THE THREADEnd-to-end encryption ↗
YOU’VE REACHED THE ENDBack to the reading room ↗