# Crittografia end-to-end, spiegata davvero > Cuadernos Lacre · Concetto · 18 maggio 2026 > https://solo2.net/it/quaderni/articulos/end-to-end-encryption-actually-explained.html Cosa dicono i fornitori quando dicono E2EE, e cosa non dicono. Una spiegazione didattica del meccanismo e dei suoi limiti, senza l'involucro pubblicitario. --- > Per intenderci: WhatsApp dice che i tuoi messaggi sono crittografati end-to-end. È vero — e non è sufficiente. Se il backup va su iCloud o Google Drive senza crittografia aggiuntiva, la crittografia si rompe sul tuo stesso telefono. La domanda operativa non è se sia crittografato, ma dove risiedono le chiavi. ## Cosa significa crittografare, davvero Crittografare un messaggio significa trasformarlo in qualcosa che sembri rumore per chiunque non possieda una certa informazione chiamata chiave. L'operazione viene eseguita sul dispositivo di chi invia e, con la chiave corretta, viene annullata sul dispositivo di chi riceve. Nel mezzo, il messaggio viaggia come una successione di byte senza significato apparente. Questa è l'idea semplice. Il resto dell'articolo si occupa delle sfumature che la rendono, a seconda dei casi, una garanzia reale o un'etichetta di mercato. L'aggettivo *end-to-end* — dall'inglese *end-to-end*, abbreviato E2EE — aggiunge una precisione. La crittografia non viene fatta affinché un server intermedio possa leggerla e consegnarla. Viene fatta affinché solo i due estremi — il dispositivo di chi invia e il dispositivo di chi riceve — possiedano la chiave. Qualsiasi server attraverso il quale il messaggio passa vede il rumore, non il messaggio. Questa è la differenza tecnica con la crittografia *in transito*, dove il contenuto viaggia crittografato da un server all'altro, ma ogni server attraverso il quale passa lo decrittografa per reinviarlo, recuperando temporaneamente il testo in chiaro. ## Il paradosso del segreto condiviso C'è un problema ovvio. Affinché due persone possano crittografare e decrittografare messaggi tra loro, entrambe hanno bisogno della stessa chiave. Ma come concordano questa chiave se tutto ciò che si inviano, per definizione, passa attraverso un canale dove qualcuno potrebbe essere in ascolto? Concordare la chiave nello stesso canale dove poi la useranno sembra impossibile: se l'attaccante la sente al momento dell'accordo, potrà decrittografare tutto il seguito. Per decenni, la crittografia classica ha risolto questo problema con le maniere forti: le chiavi venivano consegnate di persona, prima di iniziare a essere utilizzate, in incontri fisici. Gli ambasciatori portavano valigette di chiavi cucite nella fodera del cappotto. Nella posta elettronica contemporanea, questa soluzione non è scalabile. Se dovessimo andare fisicamente a casa di ogni persona con cui intendiamo comunicare in modo crittografato, non riusciremmo a parlare con nessuno. La domanda posta cinquant'anni fa dalla comunità crittografica era questa: è possibile che due persone che non si conoscono e che condividono solo un canale pubblico concordino, su quello stesso canale pubblico, un segreto che nessuno in ascolto sul canale possa conoscere? ## L'eleganza di Diffie-Hellman Nel 1976, due matematici di nome Whitfield Diffie e Martin Hellman dimostrarono qualcosa di apparentemente impossibile: che due persone, parlando solo attraverso un canale pubblico — un canale dove chiunque può sentire tutto ciò che dicono —, possono concordare una password segreta senza che nessun ascoltatore possa scoprirla. Sembra magia. Non lo è: è matematica. Lo scambio di chiavi Diffie-Hellman, come è noto da allora, è la base di quasi tutta la comunicazione crittografata su Internet, e mezzo secolo di uso intensivo e di scrutinio accademico mondiale ne confermano la solidità. Chi vuole vedere l'intuizione visiva o la matematica può continuare a leggere. Chi preferisce fidarsi del fatto che funzioni può anche proseguire senza perdere il filo dell'articolo. Per chi vuole intuirlo in un'immagine, c'è un'analogia nota con i colori. Immagina che Alice e Bruno concordino apertamente un colore di base — diciamo il giallo — sotto gli occhi di Eva, che li ascolta. Ognuno sceglie in privato un secondo colore segreto e mescola il proprio segreto con il giallo. Alice ottiene un arancione particolare; Bruno ottiene un verde particolare. Si scambiano i risultati sotto gli occhi di Eva. Ora ognuno mescola il colore ricevuto con il proprio segreto, ed entrambi arrivano allo stesso colore finale, perché l'ordine delle mescolanze non conta. Eva ha visto il giallo e le due mescolanze intermedie, ma non i segreti; senza uno dei segreti non può arrivare al colore finale. La matematica reale sostituisce i colori con elevamenti a potenza in gruppi modulari o curve ellittiche, ma l'idea è la stessa: il segreto condiviso viene costruito in pubblico senza che nessuno nel canale possa ricostruirlo. ## Da Diffie-Hellman al protocollo Signal La crittografia end-to-end utilizzata oggi dalle applicazioni di messaggistica professionale poggia, quasi senza eccezioni, su un'elegante e indurita versione dello scambio Diffie-Hellman. Il protocollo Signal, progettato da Trevor Perrin e Moxie Marlinspike tra il 2013 e il 2016, è il riferimento. Combina due idee chiave. La prima, lo scambio di chiavi in curve ellittiche (X25519), che produce il segreto condiviso iniziale tra due dispositivi. La seconda, il cosiddetto Double Ratchet — ingranaggio doppio —, che rinnova le chiavi automaticamente con ogni messaggio, in modo che la compromissione del dispositivo oggi non permetta di decrittografare i messaggi passati, né i messaggi futuri una volta che l'ingranaggio è stato ruotato. ## Cosa protegge la crittografia end-to-end Ciò che l'E2EE protegge bene, assumendo un'implementazione corretta, è il contenuto del messaggio in transito. Un server intermedio che riceva e reinvii i dati crittografati vedrà una successione di byte inintelligibili. Un attaccante con accesso al cavo, al router, al punto di accesso wifi, vedrà lo stesso. Un fornitore di servizi che conservi copie del traffico non potrà leggerlo a posteriori. Un Governo che ordini all'operatore del servizio di consegnare il contenuto riceverà gli stessi byte inintelligibili che il server aveva in primo luogo. Questo, in termini pratici, è molto. È la differenza tra lo scrivere una lettera dentro una busta opaca e lo scriverla su una cartolina. Entrambe arrivano. Solo una preserva il contenuto di fronte al postino. ## Cosa non protegge la crittografia end-to-end Conviene saperlo altrettanto bene. L'E2EE non protegge i metadati: il server sa ancora che l'utente A invia dati all'utente B, a che ora, con quale frequenza e da dove, anche se non sa cosa dice. Questi metadati, come abbiamo già argomentato in *Crittografare non significa essere privati*, sono spesso più rivelatori del contenuto. Sapere che qualcuno ha chiamato uno studio legale specializzato in divorzi un venerdì alle 22:00 per trenta minuti racconta una storia che il contenuto della chiamata non ha mai raccontato. È la stessa situazione di vedere una persona entrare e uscire più volte da una clinica oncologica: non c'è bisogno di sentire nulla di ciò che si dice all'interno per immaginare cosa stia succedendo. Un singolo metadato isolato può non significare nulla; diversi incrociati tra loro disegnano qualcosa di troppo simile alla verità. L'E2EE non protegge gli estremi: se il dispositivo del ricevente è compromesso da un programma dannoso, il messaggio viene decrittografato normalmente per quel ricevente e il programma dannoso lo legge. L'E2EE non protegge dall'identità dell'interlocutore in sé: se Alice crede di parlare con Bruno ma un attaccante si è interposto all'inizio (un *man in the middle*) e il protocollo non include una verifica indipendente, le due parti finiscono per parlare con l'intruso pensando di parlare tra loro. C'è una quarta cosa che conviene formulare senza ambiguità. L'E2EE non impedisce che un fornitore che afferma di offrirlo conservi, inoltre, una copia del messaggio non crittografato nei propri sistemi. L'affermazione «i miei messaggi sono crittografati end-to-end» e l'affermazione «il fornitore non conserva il mio contenuto» non sono la stessa cosa. Un'applicazione può rispettare la prima mentre viola la seconda; lo abbiamo visto nei titoli di stampa ripetutamente dal 2018. L'utente, a meno che il codice del client non sia verificabile, non ha alcun modo tecnico di distinguere un caso dall'altro senza un'investigazione esperta. Il caso più noto al grande pubblico: WhatsApp crittografa i messaggi end-to-end in transito, ma se l'utente attiva la copia di sicurezza su iCloud o Google Drive senza crittografia aggiuntiva, quella copia viene memorizzata leggibile nell'infrastruttura di un terzo, e la crittografia si rompe all'estremo dell'utente stesso. ## La domanda che l'operatore non vuole sentire Un'applicazione che afferma di crittografare end-to-end può, tecnicamente, fare una di tre cose riguardo alle chiavi: La domanda operativa, quindi, non è se qualcosa sia crittografato, ma chi abbia il controllo del dispositivo e del software che gestisce le chiavi. In Solo2, le chiavi risiedono unicamente nella tua Bóveda (IndexedDB crittografata con la tua password) e il software è codice sorgente aperto verificabile. ## Per il lettore professionale La crittografia end-to-end è uno strumento di sovranità digitale. Ma come ogni strumento, la sua efficacia dipende dalla mano che lo impugna e dal suolo su cui poggia. 1. Dove vengono generate le chiavi crittografiche e dove risiedono fisicamente? Se l'operatore può accedervi (anche temporaneamente, anche sotto le spoglie del recupero), l'E2EE è nominale. 2. Esiste una verifica indipendente dell'interlocutore (numeri di sicurezza, codici QR, confronto fuori banda) che prevenga un attacco man-in-the-middle durante lo stabilimento della conversazione? 3. Il codice del client è verificabile — aperto, pubblicato, riproducibile — o richiede di fidarsi della parola del fornitore su ciò che il client fa realmente? 4. Quali metadati genera e conserva il servizio, e per quanto tempo? Anche se il contenuto è opaco, i metadati possono ricostruire buona parte delle informazioni sensibili. Queste quattro domande non richiedono informazioni tecniche avanzate; richiedono informazioni a cui qualsiasi operatore onesto può rispondere nella sua documentazione pubblica. La qualità e la precisione della risposta dicono sul prodotto tanto quanto la risposta stessa. --- *La crittografia end-to-end, fatta bene, è una delle costruzioni più raffinate che la crittografia contemporanea abbia consegnato alla pratica quotidiana. L'idea originale — due persone possono concordare un segreto su un canale pubblico — appartiene a Whitfield Diffie e Martin Hellman, 1976; mezzo secolo dopo continuiamo a viverne le conseguenze. Ma, come accade con ogni promessa tecnica, il suo valore dipende dall'effettivo adempimento, non dall'etichetta. La domanda del professionista onesto non è «è crittografato?», ma «chi ha le chiavi?». Le risposte hanno conseguenze diverse. Conviene saperlo.* ## Fonti e letture aggiuntive - Diffie, W.; Hellman, M. — *New Directions in Cryptography*, IEEE Transactions on Information Theory, novembre 1976. Articolo fondante della crittografia a chiave pubblica. - Perrin, T.; Marlinspike, M. — *The Double Ratchet Algorithm*, specifica pubblica di Open Whisper Systems, revisione 2016. Base del protocollo Signal e dei suoi derivati industriali. - RFC 7748 — Elliptic Curves for Security (IETF, gennaio 2016). Specifica normativa delle curve X25519 e X448 utilizzate nei moderni scambi di chiavi. - Ferguson, N.; Schneier, B.; Kohno, T. — *Cryptography Engineering: Design Principles and Practical Applications* (Wiley, 2010). Capitoli sullo scambio di chiavi e sui protocolli di crittografia autenticata. - Regolamento (UE) 2024/1183 sul quadro europeo relativo a un'identità digitale (eIDAS 2) — stabilisce quadri in cui la verifica indipendente dell'interlocutore acquisisce supporto istituzionale, e dove la distinzione tra crittografia nominale e reale ha conseguenze giuridiche diverse. --- *Cuadernos Lacre · Una pubblicazione di Menzuri Gestión S.L. · scritta da R.Eugenio · a cura del team di Solo2.* *https://solo2.net/it/quaderni/*