La domanda utile non è se la crittografia sembri potente, ma che cosa protegga, chi detenga le chiavi e quali prove sostengano la dichiarazione.
«Crittografia di grado militare» non fornisce informazioni sufficienti per valutare un’app di messaggistica. L’espressione non dice chi detiene le chiavi, quali conversazioni sono protette, se i backup espongono testo in chiaro o che cosa succede quando un dispositivo viene compromesso.
La risposta utile non è liquidare la crittografia, ma sostituire un’etichetta impressionante con affermazioni specifiche e verificabili.
AES-256 è una scelta di algoritmo, non un modello di sicurezza completo
AES è uno standard pubblico, non una tecnologia militare segreta. Il FIPS 197 del NIST specifica AES-128, AES-192 e AES-256; il suffisso indica la lunghezza della chiave. Lo standard è stato aggiornato sul piano editoriale nel 2023, senza modificare l’algoritmo.
Un cifrario robusto può comunque essere usato in un sistema che consente al servizio di accedere al testo in chiaro. Chiedi chi può decifrare, non soltanto quanto è lunga la chiave. Chiedi anche come vengono generate e conservate le chiavi, come vengono autenticate le identità e quali condizioni di errore fanno arrestare l’applicazione anziché proseguire in modo insicuro.
Quando un fornitore cita AES-GCM, è più preciso che nominare soltanto AES: GCM combina crittografia e autenticazione. La corretta gestione dei nonce, la verifica dei tag di autenticazione e gli altri requisiti di implementazione restano importanti. La specifica GCM del NIST è il riferimento tecnico; un logo non dimostra che un’app la implementi correttamente.
Quattro affermazioni diverse che il marketing spesso confonde
| Affermazione | Che cosa riguarda | Che cosa non dimostra |
|---|---|---|
| Crittografia del trasporto | Protezione lungo una connessione, per esempio dall’app al server | Che il server non possa leggere il contenuto |
| Crittografia dei dati a riposo | Protezione dei dati memorizzati secondo uno specifico modello di chiavi e accesso | Che il gestore non possieda la chiave di decifratura |
| Crittografia end-to-end | Protezione del contenuto tra gli endpoint designati | La sicurezza di un endpoint compromesso o l’onestà di un destinatario |
| Instaurazione di chiavi post-quantistica | Resistenza a minacce quantistiche specificate durante l’instaurazione delle chiavi | Un audit completo dell’app, anonimato o sicurezza futura garantita |
La crittografia del trasporto non implica che ogni database del fornitore memorizzi testo in chiaro non protetto. Un servizio può anche cifrare i dati conservati. La distinzione rilevante è se il fornitore controlli le chiavi o abbia comunque accesso al contenuto leggibile. Sii preciso, invece di sostituire uno slogan con un altro.
Per un’introduzione più ampia, consulta che cosa protegge la crittografia end-to-end.
«Usa uno standard NIST» non significa «convalidato FIPS»
FIPS 203 definisce ML-KEM, un meccanismo di incapsulamento delle chiavi. Un’app di messaggistica può dichiarare di usare questo algoritmo senza che l’intera applicazione sia certificata o sottoposta a una revisione indipendente. Standard, test degli algoritmi, convalida dei moduli crittografici e audit di sicurezza dei prodotti sono tipi diversi di prova.
Il Cryptographic Module Validation Program del NIST chiarisce che implementare funzioni approvate non basta a dimostrare la convalida di un modulo secondo FIPS 140. Se un prodotto pubblicizza una convalida, chiedi il certificato, il modulo e la versione esatti, l’ambiente operativo e la configurazione approvata. Poi stabilisci quale parte del prodotto sia effettivamente coperta dal certificato.
È anche per questo che «sicurezza a 256 bit» non dovrebbe essere usata come valutazione complessiva di un’intera app di messaggistica. La composizione dei protocolli, la gestione delle chiavi e l’implementazione possono imporre limiti diversi.
L’autenticazione tramite password non è crittografia dei messaggi
Un meccanismo di accesso stabilisce se un utente può accedere a un account. E2EE stabilisce chi può leggere il contenuto protetto dei messaggi. Nessuno dei due fornisce automaticamente le proprietà dell’altro.
Per esempio, SRP è progettato per autenticare senza trasmettere la password stessa. Questo non significa che un database di autenticazione rubato sia innocuo. La discussione sulla sicurezza di SRP in RFC 5054 spiega che un verificatore rubato consente attacchi per tentativi sulle password e comporta altri rischi. Evita la conclusione «non ci sono password da rubare, quindi una violazione del server non può avere conseguenze».
In pratica, i lettori dovrebbero chiedere informazioni sul recupero dell’account, sulle sessioni attive e sul rapporto tra accesso all’account e chiavi di crittografia. Una risposta che ripete soltanto «conoscenza zero» lascia irrisolte le domande importanti.
Cinque domande per valutare la pagina sulla sicurezza di un’app di messaggistica
- Quali ambiti sono coperti? Chat dirette, gruppi, file, chiamate, post pubblici e backup possono avere confini diversi.
- Chi detiene chiavi utilizzabili? Includi chiavi di recupero, dispositivi collegati e modalità di elaborazione lato server.
- Come viene autenticato l’altro endpoint? Cerca verifica delle chiavi, avvisi significativi sui cambiamenti e un modello di fiducia documentato.
- Quali prove esistono? Specifiche, build riproducibili, vettori di test e audit indipendenti rispondono a domande diverse. Chiedi versione e ambito di ciascuno.
- Che cosa rimane visibile o vulnerabile? Metadati, dispositivi compromessi, messaggi copiati e contenuti pubblici non devono sparire dalla spiegazione.
Applica lo stesso esame a Livara. La sua documentazione sulla sicurezza cita LVR1 e LGS1 e pubblica i limiti operativi. Considerali dichiarazioni sul prodotto da valutare, non una certificazione indipendente. Il Proof Lab offre dimostrazioni limitate e verifiche degli artefatti, non la prova che ogni funzione o versione sia sicura.
Come leggere un audit indipendente
Controlla data, revisore, revisione del codice, piattaforme incluse e componenti esclusi. Leggi i risultati e lo stato degli interventi correttivi, non soltanto il bollino riepilogativo. L’audit di una libreria crittografica non copre automaticamente il recupero dell’account, l’app web, le notifiche o la sicurezza operativa.
L’assenza di un audit è una lacuna nelle garanzie disponibili, non la prova di una vulnerabilità specifica. Viceversa, un audit non è una garanzia a vita. Un confronto utile registra le prove e i loro limiti invece di proclamare un vincitore universale come «il più sicuro».
Domande frequenti
«Di grado militare» è sempre un altro nome per AES-256?
No. Non dedurre un algoritmo o una certificazione specifici da questa espressione. Chiedi al fornitore di dichiarare esattamente che cosa intende.
Una crittografia più forte impedisce screenshot o malware?
Non impedisce a un destinatario di copiare contenuti né a un dispositivo compromesso di esporre i dati a cui può accedere. Sono minacce diverse.
Che cosa è più significativo di uno slogan sulla sicurezza?
Un ambito chiaro, un protocollo identificato, limiti espliciti e prove esaminabili sull’implementazione distribuita. La spiegazione dovrebbe aiutarti a decidere di che cosa fidarti e che cosa debba ancora essere verificato.
