L’agilità crittografica è la capacità di passare un protocollo da una suite crittografica a un’altra senza perdere un insieme chiaro di garanzie di sicurezza. Nella messaggistica, significa più che aggiungere il nome di un nuovo algoritmo. I vecchi client, i destinatari offline, i messaggi archiviati e i dispositivi collegati devono tutti comportarsi in modo prevedibile durante la transizione.
L’RFC 7696 dell’IETF descrive l’agilità degli algoritmi come un problema di migrazione che coinvolge identificatori, implementazioni e cambiamenti operativi. Un numero di versione aiuta a identificare ciò che viene utilizzato; da solo non rende sicura la migrazione.
Tre versioni facili da confondere
Un’app di messaggistica può avere una versione dell’app, una versione del protocollo di comunicazione e un identificatore della suite crittografica. Rispondono a domande diverse:
| Identificatore | Cosa indica a chi esamina il sistema | Cosa non dimostra |
|---|---|---|
| Release dell’app | Quale build del software è installata | Che ogni conversazione usi il protocollo più recente |
| Versione del protocollo | Quale formato dei messaggi e quali regole di stato si applicano | Che l’implementazione segua correttamente tali regole |
| Identificatore dell’algoritmo o della suite | Quali componenti crittografici sono selezionati | Che la negoziazione non possa essere degradata a un’opzione più debole |
Le note di rilascio dovrebbero rendere esplicita questa relazione. «Nuova cifratura disponibile» è ambiguo se la usano soltanto le nuove conversazioni o se un vecchio client collegato provoca un ripiego su una modalità precedente.
Cosa deve specificare una migrazione sicura
Partiamo da uno scenario concreto: Alice aggiorna oggi; Bob resta offline con un vecchio telefono. Alice invia un messaggio e in seguito aggiunge un secondo dispositivo. Cosa dovrebbe accettare, archiviare e mostrare ogni dispositivo?
Un progetto verificabile risponde almeno a queste domande:
- Come scopre ciascuna parte le versioni supportate dall’altra?
- La versione selezionata viene autenticata come parte della sessione?
- Cosa accade quando non esiste una versione accettabile condivisa?
- Un relay malevolo può eliminare una capacità e indurre una modalità più debole?
- I vecchi messaggi restano leggibili e quali vecchie chiavi rimangono necessarie?
- Il ripristino di un backup riattiva uno stato obsoleto del protocollo?
- Quando verranno disabilitati gli algoritmi deprecati, invece di limitarsi a sconsigliarli?
Un errore visibile è spesso più sicuro di una transizione silenziosa verso una modalità che l’utente non intendeva usare. Il comportamento esatto in caso di errore e durante il recupero dovrebbe però essere documentato, affinché le persone non lo aggirino passando a un canale non protetto.
Una matrice pratica di test per gli aggiornamenti
Un aggiornamento di sicurezza richiede più di una chat riuscita tra due installazioni nuove. Prova questi casi con dati non sensibili:
| Test | Evidenze da registrare |
|---|---|
| Nuovo client verso vecchio client | Protocollo selezionato o esito chiaro di incompatibilità |
| Destinatario offline durante l’aggiornamento | Comportamento di consegna e decifratura dopo la riconnessione |
| Ritorna un vecchio dispositivo collegato | Se può leggere, inviare o imporre una modalità imprevista |
| Un gruppo aggiunge un membro incompatibile | Politica esplicita del gruppo e stato visibile all’utente |
| Backup ripristinato dopo la dismissione di vecchi meccanismi | Se lo stato non supportato viene rifiutato o migrato |
| Metadati di versione manomessi | Errore di autenticazione anziché un downgrade inosservato |
Questi sono criteri di valutazione, non affermazioni che un prodotto citato abbia superato i test. Conserva gli identificatori delle build e gli esiti osservati, così da distinguere una regressione successiva da una modifica della documentazione.
Come interpretare i nomi dei protocolli di Livara
Nella sua documentazione di sicurezza, Livara indica LVR1 per le chat dirette e LGS1 per i gruppi privati. Questi nomi distinguono le responsabilità; non devono essere letti come prova di standardizzazione o audit indipendenti. La pagina tratta anche il comportamento di client o gruppi che non possono soddisfare i prerequisiti della modalità cifrata.
Le prossime evidenze utili sarebbero una specifica versionata, vettori di test, regole di compatibilità e risultati di revisione riferiti a una release precisa. Il Proof Lab dichiara esplicitamente l’ambito più limitato della propria dimostrazione. Eseguire primitive in un browser non equivale a testare ogni percorso di migrazione nell’app.
Cosa dovrebbero fare gli utenti durante un aggiornamento della cifratura
Mantieni aggiornati i client supportati, leggi gli avvisi di sicurezza sulla compatibilità dei dispositivi e presta attenzione ai cambiamenti degli indicatori di identità o dello stato della cifratura. Non presumere che una nuova icona dell’app significhi che tutti i vecchi gruppi e backup abbiano acquisito una nuova protezione. Se il prodotto non sa spiegare per quali dati è cambiata la protezione, chiedi prima di condividere materiale sensibile.
Una buona agilità crittografica rende il cambiamento verificabile. Identifica cosa è cambiato, come le parti lo concordano, cosa può andare storto e quando il vecchio meccanismo smette di essere accettato.
