Cifratura end-to-end

La maggior parte del web cifra già in due modi diversi da questo. La cifratura in transito (TLS, il lucchetto) protegge i dati tra il tuo dispositivo e un server, ma il server poi li legge. La cifratura a riposo protegge un disco, eppure l’azienda che lo possiede di solito detiene anche la chiave. La cifratura end-to-end toglie la chiave dalle mani dell’azienda: anche una violazione del server, un ordine del tribunale all’operatore o un dipendente curioso producono solo byte illeggibili. Le app di messaggistica hanno reso familiare l’idea: un messaggio viene sigillato su un telefono e aperto su un altro, così nemmeno l’azienda che lo trasporta sa cosa dica, solo che qualcosa è stato inviato. Progetti aperti come il protocollo Signal mostrano che l’approccio regge dalle coppie di amici ai grandi gruppi.

In pratica un dispositivo genera una chiave, la usa per cifrare ogni elemento prima dell’invio e la dà solo ai dispositivi che approvi. La parte difficile non è il cifrario, che è standard (AES-256-GCM è molto usato), ma le chiavi: come un nuovo dispositivo ne riceve una, e cosa succede se le perdi tutte. I veri sistemi end-to-end rispondono con una passkey, una chiave di recupero o un dispositivo già fidato, e accettano un compromesso. Poiché nessun altro può aprire i tuoi dati, nessun altro può nemmeno salvarli. Pensa a una lettera in una scatola chiusa: il corriere la maneggia per tutto il tragitto, ma solo chi ha la chiave giusta legge cosa c’è dentro.

Conosci anche i limiti. Protegge i dati dal server, non da un dispositivo compromesso, da un telefono sbloccato rubato o da un malware. E una chat con l’IA non può essere end-to-end fino al modello: il modello deve leggere il testo per rispondere. Il termine si adatta quindi ad archiviazione, sincronizzazione, backup e condivisione, non allo scambio dal vivo con il modello. Una prova utile è chiedersi chi detiene la chiave. Se la risposta è l’operatore, il servizio può essere cifrato, ma non è end-to-end, e l’operatore può essere costretto o violato.

Al primo uso il tuo browser crea una chiave AES-256-GCM non esportabile: la pagina può usarla per cifrare e decifrare, ma nessuno script può leggerla come byte, nemmeno il nostro. Conversazioni, immagini, personaggi e memoria sono cifrati con essa prima di essere scritti nel database del browser. Se attivi la sincronizzazione nelle Impostazioni, ogni elemento viene cifrato nel tuo browser con una chiave dati che i nostri server non hanno mai, e il suo id è reso opaco. Quella chiave è avvolta dalla tua passkey e dalla tua chiave di recupero, e sigillata per ogni dispositivo approvato; ogni richiesta di sincronizzazione deve essere firmata da un dispositivo approvato. Senza una passkey, una chiave di recupero o un altro dispositivo approvato, la nostra copia non si può più aprire.

Anche i link di condivisione e il backup sono cifrati, il backup con la tua passphrase. La parte che non è end-to-end è la risposta stessa: il tuo messaggio passa dai nostri server al modello e ritorna, e la pagina di trasparenza dichiara che non è scritto né nel database né nei registri. Per questo conserviamo solo elementi sigillati: una fuga dal database esporrebbe byte illeggibili, dimensioni arrotondate per eccesso e orari, nessuna delle parole che hai scritto.