La cifratura indica quali chiavi aprono un messaggio; occorre verificare separatamente chi ha ricevuto quelle chiavi.
No: la crittografia end-to-end di un gruppo non impedisce da sola la presenza di un membro nascosto. La risposta a «Il server può aggiungere un membro al gruppo?» dipende dai meccanismi di appartenenza e verifica dei membri, non soltanto dalla cifratura dei messaggi. Secondo la documentazione di Livara, LGS1 cifra i contenuti nei gruppi privati compatibili che operano effettivamente in modalità E2EE. La rotazione delle chiavi dopo una modifica dei membri serve a limitare l’accesso futuro e richiede che gli aggiornamenti di appartenenza e delle chiavi siano applicati sui dispositivi; non recupera copie già ricevute.
Punti principali
- La crittografia end-to-end mira alla riservatezza dei messaggi, ma la sicurezza dell’elenco dei membri richiede un meccanismo distinto.
- In un gruppo privato Livara compatibile con stato E2EE confermato, LGS1 copre messaggi, modifiche e chiavi degli allegati; non estendete questa affermazione ai vecchi gruppi incompatibili.
- Confrontare Signal, WhatsApp, SimpleX ed Element soltanto attraverso l’etichetta «cifrato» non basta: contano anche le notifiche di modifica dei membri, il ruolo degli amministratori e i metodi di verifica dell’identità.
- L’interfaccia non può rilevare in ogni circostanza un account autorizzato controllato da un attaccante; i membri devono verificare identità e cambiamenti sensibili tramite un percorso indipendente.
- Proof Lab di Livara offre una dimostrazione locale di P-256, HKDF e AES-GCM e il controllo degli hash dei file; non è un’implementazione completa né un audit indipendente di LVR1/LGS1.
La cifratura dei gruppi impedisce i membri nascosti?
No, a meno che il protocollo coordini tra i membri anche lo stato di appartenenza in modo crittografico e verificabile, oltre ai contenuti. In questo articolo «membro nascosto» indica un account che accede ai messaggi futuri senza che i membri umani ne abbiano notato l’ingresso o riconosciuto correttamente l’identità.
La crittografia end-to-end significa che soltanto i dispositivi dei partecipanti dovrebbero poter leggere il contenuto; ma questi dispositivi devono anche sapere a chi inviano le chiavi. Se il server può modificare l’elenco dei destinatari, la cifratura può funzionare correttamente e tuttavia cifrare un messaggio anche per un membro indesiderato. Per distinguere contenuto e metadati, consultate la guida alla crittografia end-to-end e ai suoi limiti.
Un «attacco del server a un gruppo cifrato» non significa quindi necessariamente violare AES o risolvere un problema matematico. Attraverso il controllo dell’appartenenza, il server potrebbe aggiungere un account valido ai destinatari futuri. I messaggi precedenti di cui quell’account non possedeva le chiavi sono una questione separata; il rischio principale è l’accesso dopo l’ingresso.
Che cosa sappiamo dell’appartenenza ai gruppi Livara?
La documentazione di sicurezza di Livara distingue il controllo del server su membri e ruoli dalla cifratura del contenuto. È un confine importante da valutare, ma da solo non dimostra un attacco pratico riuscito o un ingresso completamente invisibile. Per sostenerlo occorrerebbe testare comportamento del client, distribuzione delle chiavi, notifiche di modifica dei membri e condizioni dell’attacco.
La domanda giusta è: i dispositivi convalidano indipendentemente le modifiche all’elenco e che cosa viene mostrato all’utente prima di inviare una chiave a un nuovo membro? Questo articolo non presenta risultati di audit o penetration test di Livara.
Come cambia la sicurezza dell’elenco dei membri in cinque app di messaggistica?
Le differenze principali riguardano chi autorizza le modifiche, come ne vengono informati i membri e se possono verificare indipendentemente l’identità di un nuovo account. La sola presenza di E2EE non risponde completamente alla domanda sulla fiducia nel server.
| App | Contenuti del gruppo | Appartenenza e fiducia pratica | Conclusione prudente |
|---|---|---|---|
| Livara | In un gruppo privato compatibile con E2EE, LGS1 copre testo, modifiche e chiavi degli allegati. | Le chiavi dei mittenti vengono rigenerate e ridistribuite automaticamente quando cambiano i membri. | Secondo la documentazione del prodotto, contenuti dei gruppi privati compatibili e chiavi multimediali sono protetti prima della consegna; verificate lo stato di quel gruppo specifico. |
| Signal | L’assistenza Signal sui gruppi afferma che il servizio non registra membri, titolo, immagine o attributi del gruppo. | La stessa fonte indica che l’amministratore può stabilire chi aggiunge membri e attivare l’approvazione per i link del gruppo; i membri devono comunque osservare le modifiche. | Il progetto limita ciò che il servizio conosce, ma gli utenti devono controllare cambiamenti dei membri e identità degli account. |
| La panoramica sulla cifratura WhatsApp afferma che messaggi personali e di gruppo sono cifrati end-to-end. | La risorsa di assistenza WhatsApp descrive la condivisione facoltativa di parte della cronologia con un nuovo membro e il potere dell’amministratore di limitarla. | Il contenuto è cifrato, ma la correttezza dell’appartenenza va valutata attraverso controlli amministrativi e notifiche dell’app. | |
| SimpleX | La documentazione dei gruppi SimpleX afferma che ogni membro ha collegamenti separati con gli altri. | La specifica descrive i gruppi come un insieme di connessioni tra membri, con ruoli e messaggi di modifica dell’appartenenza; ciò non esclude un amministratore umano. | Un gruppo senza identificatore globale non elimina tutti i rischi di appartenenza o quelli dei dispositivi compromessi. |
| Element / Matrix | La specifica E2EE di Matrix definisce l’evento m.room.encryption e gli algoritmi di cifratura delle stanze. |
La specifica dell’appartenenza di Matrix modella i membri tramite eventi m.room.member nello stato della stanza, distribuito dagli homeserver. |
Cifratura della stanza e stato di appartenenza sono livelli distinti; i membri devono controllare dispositivi e modifiche della stanza. |
Questa tabella non è una classifica assoluta. Ogni sistema ha un modello di minaccia diverso e app, dispositivo, amministrazione e comportamento dei membri possono cambiare il risultato. Per una scelta pratica, usate le 12 domande della checklist per la messaggistica sicura insieme alla documentazione ufficiale di ogni prodotto.
Come confrontare la fiducia nel server delle app di messaggistica?
Non riducete la fiducia a un sì o un no: chiedete precisamente che cosa il server vede e può modificare. Un server che non legge il testo potrebbe comunque controllare i tempi delle comunicazioni, i membri o la distribuzione delle chiavi iniziali.
Primo: distinguere la riservatezza del contenuto
Verificate esattamente dove vengono cifrati messaggi, modifiche, reazioni, titoli, allegati e relative chiavi. Secondo la documentazione di Livara, LGS1 copre testo, modifiche e chiavi degli allegati nei gruppi privati compatibili con E2EE; questa affermazione non include i canali.
Secondo: individuare l’autorità sull’appartenenza
Stabilite chi può invitare membri, chi approva le richieste e come il client mostra i cambiamenti. Se il server impone lo stato del gruppo, la sua compromissione deve comparire esplicitamente nel modello di minaccia.
Terzo: separare identità e appartenenza
Un nome familiare non dimostra che una chiave appartenga a quella persona. In Livara, il numero di sicurezza consente di confrontare le impronte delle chiavi fuori dall’app; la presenza dello strumento non significa di per sé che sia stato verificato l’intero elenco dei membri. Attribuite anche la trasparenza delle chiavi a un prodotto soltanto se documentata.
Quarto: distinguere prove e affermazioni
Documentazione, rapporti di audit e test indipendenti non sono equivalenti. Un rapporto attendibile deve specificare versione, ambito, risultati e correzioni. Il nome di un algoritmo o l’accordo tra due implementazioni non prova da solo la sicurezza della gestione dei membri.
Come si verificano i membri di una chat di gruppo?
I membri devono esaminare subito le modifiche dell’elenco e verificare le identità sensibili tramite un canale indipendente. Per conversazioni ad alto rischio non basta vedere nome, foto o numero di account: questi segnali possono essere errati, riciclati o controllati da un attaccante.
In Livara, due persone possono confrontare il numero di sicurezza di persona, in una chiamata conosciuta o attraverso un percorso indipendente. Questo può rivelare una modifica inattesa della chiave; tuttavia, un confronto tra due persone non copre automaticamente tutti i membri di un grande gruppo contemporaneamente. La guida alla verifica delle chat tramite numero di sicurezza spiega i passaggi pratici.
Per gruppi sensibili è utile questa breve procedura:
- Limitate il più possibile agli amministratori la facoltà di aggiungere membri.
- Controllate immediatamente ogni notifica di ingresso, uscita o cambio di ruolo.
- Verificate l’identità di un nuovo membro fuori da quello stesso gruppo.
- Dopo una modifica sospetta, smettete di inviare informazioni sensibili e create un nuovo gruppo con membri verificati.
- Esaminate periodicamente dispositivi e sessioni collegati a ogni account.
Queste misure riducono il rischio, ma non riparano un difetto dell’architettura di appartenenza. Se il server o l’account amministratore è compromesso e l’interfaccia mostra male le modifiche, l’utente potrebbe ancora non accorgersi di un ingresso.
Domande frequenti
Il server può aggiungere un membro senza violare la cifratura?
Sì, se l’architettura dell’app affida al server il controllo dell’elenco. In tal caso non deve violare il cifrario: può aggiungere un account ai destinatari futuri affinché i client cifrino anche per quell’account. Possibilità e modalità dipendono dal protocollo di appartenenza di ogni prodotto.
Come funziona LGS1 nei gruppi Livara?
Secondo la documentazione, nei gruppi privati compatibili con E2EE, LGS1 utilizza una catena di chiavi e firme del mittente per proteggere contenuti e chiavi degli allegati. Limitare l’accesso futuro dopo un’uscita dipende dall’applicazione della modifica di appartenenza e dalla distribuzione di nuove chiavi. Proof Lab offre soltanto dimostrazioni locali di alcuni componenti crittografici e controlli degli hash; non è un’implementazione completa di LGS1, un audit del protocollo né una prova di gestione sicura dei membri.
Il confronto dei numeri di sicurezza dimostra l’ingresso di un membro nascosto?
No. Il confronto verifica l’identità delle chiavi tra due persone attraverso un percorso indipendente e può rivelare una modifica inattesa. Ma non dimostra che nessun altro membro sia entrato: occorre controllare separatamente elenco, notifiche di appartenenza e identità degli account sensibili.
Quale app ha l’elenco dei membri più sicuro?
Da queste fonti non si può ricavare un vincitore assoluto, perché Signal, WhatsApp, SimpleX, Element e Livara hanno modelli di appartenenza e di minaccia diversi. La scelta giusta dipende dal vostro rischio: verificate chi controlla l’appartenenza, come vengono annunciati i cambiamenti e se le identità sono verificabili indipendentemente dal server.
