Come trasformo WhatsApp in E2EE²: cifrare il messaggio prima che arrivi a WhatsApp

WhatsApp utilizza già la crittografia end-to-end per i messaggi personali e questo va chiarito subito perché il progetto che descrivo non nasce per “riparare” WhatsApp, ma per cambiare il punto nel quale decidiamo che il testo debba smettere di esistere in chiaro. Normalmente scriviamo il messaggio dentro l'app, WhatsApp lo riceve in chiaro sul nostro dispositivo e poi applica la propria E2EE prima di inviarlo. Quello che mi interessa fare è anticipare di un livello quel momento: il testo viene scritto dentro una tastiera Android dedicata, cifrato localmente PRIMA di essere consegnato al campo di composizione di WhatsApp e soltanto il ciphertext viene passato all'app. WhatsApp a quel punto prende una stringa che per lui non significa nulla, la tratta come un normale messaggio e la cifra nuovamente con il proprio protocollo end-to-end. Il destinatario riceve quindi, attraverso un canale già E2EE, un contenuto che è stato cifrato una prima volta da un sistema completamente indipendente.

Io lo chiamo E2EE², ma la notazione è volutamente descrittiva e non matematica. Due livelli di cifratura non significano “sicurezza al quadrato” e non raddoppiano magicamente i bit di sicurezza, quello che otteniamo è soprattutto una separazione della fiducia: la protezione esterna continua ad esistere anche se consideriamo WhatsApp soltanto come trasportatore di un blob cifrato.

La prima idea da correggere: non bisogna intercettare il buffer della tastiera

L'idea iniziale può venire spontanea: installo un servizio che intercetta in tempo reale ciò che l'utente digita, trasformo ogni carattere e consegno il risultato a WhatsApp. Tecnicamente Android possiede componenti molto potenti, ma costruire la soluzione agganciandosi in maniera invisibile ai buffer di input, ad AccessibilityService oppure ad altre tecniche di hooking ci porterebbe esattamente nel territorio nel quale lavorano keylogger e spyware e, oltre ad essere una architettura pessima per un prodotto che nasce per aumentare la riservatezza, allargherebbe enormemente la superficie di attacco.

Android possiede già il meccanismo corretto: InputMethodService, cioè l'API con la quale vengono costruite le tastiere. Una tastiera Android è un IME, Input Method Editor, e comunica con il campo che in quel momento possiede il focus attraverso InputConnection. Non abbiamo quindi bisogno di violare WhatsApp, leggere la sua memoria, fare root al telefono oppure agganciarci al processo. L'utente sceglie esplicitamente una tastiera E2EE² quando vuole scrivere un messaggio riservato e quella tastiera, invece di consegnare immediatamente ogni carattere al campo di testo dell'app, mantiene la composizione nel proprio spazio, cifra il messaggio quando l'utente preme INVIA e soltanto in quel momento esegue un commitText() del ciphertext.

Questa differenza è fondamentale perché nel modello corretto non stiamo spiando una tastiera altrui: siamo NOI la tastiera che l'utente ha volontariamente attivato.

La stessa architettura ha anche un vantaggio di sicurezza molto importante: l'IME E2EE² può essere costruito senza permesso INTERNET. Non deve inviare nulla ad un server, non deve fare analytics, non deve sincronizzare dizionari e non dovrebbe nemmeno conservare una cronologia di ciò che viene scritto. Se vogliamo portare il concetto fino in fondo, la tastiera può essere un componente offline che conosce soltanto le chiavi dei contatti, mentre WhatsApp continua ad occuparsi di rete, consegna, notifiche e multi-device.

La tavola caratteri scramblata è una bella idea visiva, ma non deve essere la crittografia

Qui c'è il secondo punto nel quale bisogna essere rigorosi. Se prendiamo un alfabeto, lo permutiamo utilizzando un seed condiviso e sostituiamo ogni A con un determinato simbolo, ogni B con un altro e così via, abbiamo costruito sostanzialmente un cifrario a sostituzione. Anche se la tavola contiene Unicode e anche se il seed è molto lungo, il sistema continua a perdere struttura: lettere uguali producono simboli uguali, parole ricorrenti producono pattern ricorrenti e frequenze, testo noto e messaggi ripetuti aiutano l'analista a ricostruire la mappatura.

Non userei quindi il seed per costruire la sicurezza. Lo utilizzerei, se vogliamo mantenere questa idea, soltanto COME INPUT per la derivazione di una chiave crittografica oppure come elemento di pairing. La cifratura vera deve essere affidata ad algoritmi moderni di authenticated encryption, per esempio AES-GCM oppure XChaCha20-Poly1305, attraverso librerie mature come Google Tink. Una AEAD non si limita a rendere il testo illeggibile ma ne protegge anche l'integrità, quindi se qualcuno cambia un solo bit del messaggio la decifratura fallisce invece di restituire silenziosamente un testo manipolato.

La tavola caratteri può semmai tornare dopo la cifratura, come semplice CODIFICA del ciphertext. Il risultato binario può essere trasformato in Base64URL oppure, se vogliamo un aspetto più particolare, in un alfabeto Unicode scelto per il trasporto. A quel punto anche una eventuale sostituzione scramblata non rappresenta più una barriera di sicurezza, ma soltanto il modo con il quale rendiamo il blob compatibile con una normale casella di testo.

Come appare realmente il flusso

Il sistema diventerebbe più o meno questo:

text

UTENTE

|

v

TASTIERA E2EE² ANDROID

buffer locale della composizione

|

v

AEAD + chiave del contatto

|

v

E2X1:<ciphertext codificato>

|

v

InputConnection.commitText()

|

v

WHATSAPP

vede soltanto il ciphertext

|

v

E2EE DI WHATSAPP

|

v

RETE / SERVER / DESTINATARIO

|

v

WHATSAPP DEL DESTINATARIO

mostra il ciphertext

|

v

APP COMPANION E2EE²

|

v

DECIFRATURA LOCALE

|

v

TESTO IN CHIARO

Questa architettura ha una conseguenza che bisogna accettare subito: se vogliamo che WhatsApp non veda mai il plaintext, allora WhatsApp NON PUÒ contemporaneamente mostrarcelo decifrato nelle proprie bolle. Il destinatario deve aprire il contenuto attraverso il layer E2EE², per esempio condividendo il messaggio cifrato con l'app companion oppure aprendolo attraverso una azione esplicita prevista dal nostro sistema. Tentare di modificare direttamente l'interfaccia di WhatsApp o leggere automaticamente le sue bolle con AccessibilityService renderebbe la soluzione invasiva e molto meno sicura.

In altre parole possiamo avere indipendenza crittografica da WhatsApp oppure perfetta integrazione grafica dentro WhatsApp senza cooperazione dell'app, ma non entrambe contemporaneamente.

La tastiera può essere molto semplice

Il cuore dell'invio non richiede codice esoterico. Immaginando che il nostro Key Manager abbia già restituito un oggetto Aead corrispondente al contatto selezionato, la parte applicativa potrebbe assomigliare a questa:

kotlin

fun encryptMessage(

plaintext: String,

aead: Aead,

aad: ByteArray

): String {

val ciphertext = aead.encrypt(

plaintext.toByteArray(Charsets.UTF_8),

aad

)

return "E2X1:" + Base64.encodeToString(

ciphertext,

Base64.NO_WRAP or Base64.URL_SAFE

)

}

Quando l'utente preme il tasto di invio della tastiera sicura non dobbiamo inserire prima il testo normale nel campo di WhatsApp e sostituirlo dopo, perché per alcuni millisecondi il plaintext sarebbe comunque appartenuto all'app. È molto meglio mantenere il buffer dentro l'IME e committare soltanto il risultato cifrato:

kotlin

fun sendEncrypted() {

val plaintext = secureBuffer.toString()

val packet = encryptMessage(

plaintext,

currentContactAead,

currentSessionId

)

currentInputConnection.commitText(packet, 1)

secureBuffer.clear()

}

È codice volutamente ridotto perché la parte difficile non è commitText(), ma la gestione corretta delle chiavi, dei nonce, delle sessioni e della verifica dell'identità del destinatario. Ed è proprio per questo che non inventerei mai un protocollo crittografico personale soltanto perché il codice apparentemente funziona.

Il vero problema è sapere con chi sto cifrando

La tastiera non dovrebbe tentare di leggere il nome della chat aperta in WhatsApp perché per farlo dovrebbe utilizzare API molto più invasive. Preferisco una soluzione più chiara: quando attivo E2EE² scelgo esplicitamente dalla tastiera il contatto crittografico, per esempio “Mario, fingerprint 8F:42:...”, e da quel momento il messaggio viene cifrato con la sessione di Mario indipendentemente da quale applicazione io stia usando.

Questo permette tra l'altro di usare lo stesso layer anche in Telegram, Messenger, SMS, email, Slack oppure in una chat aziendale qualsiasi. L'app sottostante non deve sapere nulla del nostro protocollo: trasporta soltanto testo.

Per il primo pairing farei generare ad ogni dispositivo una coppia di chiavi e scambierei la chiave pubblica attraverso QR code, possibilmente verificando di persona oppure attraverso un secondo canale un fingerprint breve. Una alternativa ancora più semplice per un prototipo è scambiare un segreto casuale di almeno 128 o 256 bit tramite QR e derivare da quello le chiavi della sessione. Quello che eviterei è una password umana tipo federico-mario-2026 usata direttamente come chiave: se si vuole partire da una passphrase occorre una KDF adatta alle password, con salt e costo computazionale adeguato.

Sul dispositivo le chiavi persistenti dovrebbero essere protette con Android Keystore e, quando disponibile, hardware-backed Keystore o StrongBox. Android permette anche di imporre che determinate chiavi possano essere utilizzate soltanto dopo autenticazione dell'utente, quindi per una modalità particolarmente riservata potremmo richiedere impronta, volto o PIN prima di aprire una sessione E2EE².

Una chiave comune per sempre sarebbe già meglio della tavola, ma non è ancora il massimo

Se due persone utilizzano per anni la stessa chiave simmetrica, un eventuale furto della chiave può compromettere un numero enorme di messaggi registrati in precedenza. Il salto successivo consiste quindi nell'introdurre forward secrecy, cioè fare in modo che ogni messaggio utilizzi chiavi che evolvono nel tempo e che la compromissione dello stato presente non permetta automaticamente di ricostruire tutta la conversazione passata.

È esattamente il tipo di problema affrontato da protocolli come Double Ratchet di Signal, nel quale ogni messaggio utilizza una propria chiave derivata e le parti inseriscono periodicamente nuovo materiale Diffie-Hellman nella catena. Per un prototipo E2EE² potrei partire da una chiave condivisa più semplice, ma se l'obiettivo dichiarato diventa “comunicazioni realmente ad alta riservatezza” non reinventerei questa parte: utilizzerei un protocollo studiato, revisionato e già sottoposto ad anni di analisi crittografica.

Questa è forse la regola più importante di tutto il progetto: possiamo inventare l'interfaccia, il formato del messaggio, la tastiera e l'esperienza utente, ma NON dobbiamo inventare la matematica crittografica.

Che cosa vede davvero WhatsApp

Se inviamo:

text

Domani alle 9 ci vediamo nel solito posto.

la tastiera potrebbe trasformarlo in qualcosa di simile a:

text

E2X1:Af8qdkQ9b4N1T7xK...7yQ

ed è questa seconda stringa che entra nel campo di composizione. WhatsApp può quindi conoscere il fatto che abbiamo inviato un messaggio ad una certa persona, l'orario, la lunghezza approssimativa del payload e gli altri metadati che appartengono al proprio servizio, ma il contenuto utile del messaggio è già cifrato da una chiave che WhatsApp non possiede.

Dopodiché la E2EE nativa di WhatsApp cifra nuovamente quel payload durante il trasporto. Da qui il nome E2EE².

La protezione aggiuntiva è particolarmente interessante se il nostro threat model comprende la volontà di non lasciare il testo leggibile nel database della chat, nei backup dell'app oppure in una eventuale esportazione della conversazione. In tutti questi casi il dato memorizzato da WhatsApp rimane il blob E2X1.

Non protegge però da tutto. Se il telefono è compromesso a livello di sistema operativo, se un malware riesce a osservare la nostra tastiera, se il dispositivo registra lo schermo mentre leggiamo la decifratura oppure se l'attaccante ottiene accesso alle chiavi del layer E2EE², la seconda cifratura può essere aggirata. E soprattutto non nasconde metadati come chi comunica con chi e quando.

Il destinatario non dovrebbe passare dal clipboard se possiamo evitarlo

La soluzione più semplice sarebbe copiare il ciphertext da WhatsApp e incollarlo nella companion app, ma il clipboard è per definizione un punto di passaggio condiviso e Android stesso dedica una documentazione specifica ai rischi derivanti dalla gestione di contenuti sensibili negli appunti. Le versioni moderne limitano molto più di prima l'accesso in background e consentono di marcare i contenuti come sensibili, ma continuo a preferire un passaggio esplicito attraverso Android Sharesheet quando l'app lo permette.

La companion app riceve il testo cifrato, controlla il prefisso e la versione del protocollo, identifica la sessione, verifica l'autenticità del ciphertext e soltanto allora mostra il plaintext dentro una Activity propria. Quella Activity dovrebbe usare FLAG_SECURE per impedire gli screenshot e la visualizzazione su display non sicuri, non dovrebbe mostrare il contenuto nelle notifiche e dovrebbe cancellare il buffer di testo appena l'utente chiude la schermata.

Se per ragioni di usabilità dovessimo usare comunque il clipboard, il contenuto dovrebbe essere marcato sensibile e cancellato il prima possibile, ma non lo considererei la strada ideale per una applicazione che nasce proprio per ridurre le copie del plaintext.

E se voglio rispondere senza cambiare continuamente app?

Qui si può rendere l'esperienza molto migliore. La companion app può mostrare il messaggio decifrato e avere un tasto RISPONDI che riattiva direttamente la tastiera sicura oppure prepara il contesto crittografico corretto, senza copiare il testo originale. L'utente torna in WhatsApp e la tastiera mostra chiaramente “E2EE² con Mario”, compone la risposta localmente e inserisce soltanto il nuovo ciphertext.

A quel punto il flusso quotidiano potrebbe diventare sorprendentemente naturale: apro WhatsApp, vedo un messaggio E2X1, lo condivido con E2EE², leggo il testo in una finestra protetta, torno alla chat e scrivo con la tastiera cifrata. Non è trasparente come una integrazione nativa, ma non richiede root, hooking o modifiche al client WhatsApp ed è proprio questa indipendenza ad avere valore.

Non userei Gboard come primo punto di acquisizione

Se il nostro obiettivo è fare in modo che il plaintext venga conosciuto dal minor numero possibile di componenti, non avrebbe molto senso scrivere prima il testo con una tastiera di terze parti e poi intercettarlo. Il vero IME E2EE² deve essere lui stesso il punto nel quale le dita diventano caratteri.

Per questo lo costruirei estremamente semplice: niente cloud dictionary, niente personalizzazione remota, nessuna telemetria, nessun accesso Internet, niente sincronizzazione e nessun apprendimento permanente delle frasi inserite. Autocorrezione e suggerimenti, se desiderati, dovrebbero utilizzare soltanto modelli e dizionari locali.

Una tastiera possiede per definizione accesso a dati estremamente sensibili, quindi la sua superficie software dovrebbe essere più piccola possibile. Potremmo perfino disabilitarne automaticamente la modalità E2EE² sui campi marcati come password e non conservare mai il testo composto una volta terminata la cifratura.

Gli allegati sono il passo successivo e, paradossalmente, sono più semplici

Per immagini, PDF e documenti non dobbiamo passare dalla tastiera. La companion app riceve il file attraverso lo Sharesheet Android, genera una chiave casuale dedicata, cifra il flusso con Streaming AEAD e produce un file con estensione, per esempio, .e2x. Soltanto quel file viene condiviso con WhatsApp come documento.

Il destinatario riceve il blob cifrato e lo apre con la companion app che autentica e decifra i segmenti.

L'architettura può essere:

text

FOTO / PDF / FILE

|

v

APP E2EE²

|

v

STREAMING AEAD

|

v

documento.e2x

|

v

WHATSAPP

|

v

E2EE WHATSAPP

|

v

DESTINATARIO

|

v

APP E2EE²

|

v

FILE DECIFRATO

Google Tink mette a disposizione proprio una primitive Streaming AEAD destinata a file e stream di grandi dimensioni, con segmenti autenticati che non possono essere riordinati o sostituiti senza essere rilevati.

C'è naturalmente un prezzo da pagare: WhatsApp non potrà produrre una anteprima dell'immagine perché per lui non è più una JPEG ma un file cifrato. È una rinuncia coerente con il nostro obiettivo, perché non possiamo contemporaneamente chiedere a WhatsApp di non conoscere l'immagine e pretendere che la decodifichi per mostrarci la miniatura.

Anche le fotografie possono restare completamente opache a WhatsApp

Per le immagini adotterei quindi lo stesso formato contenitore degli allegati, magari salvando all'interno del payload cifrato nome, MIME type, dimensioni originali, hash e thumbnail, ma lasciando fuori soltanto il minimo indispensabile per riconoscere il protocollo. Una volta ricevuto il file, la companion app può decifrarne una thumbnail in memoria e mostrare l'immagine senza salvarla nella galleria.

Se vogliamo essere ancora più rigorosi, il file decifrato non deve mai essere scritto nello storage condiviso. Può essere decodificato in memoria oppure in un file temporaneo privato dell'app, eliminato alla chiusura.

La voce richiede invece di rinunciare alla nota vocale nativa di WhatsApp

La stessa idea si estende all'audio ma qui compare una limitazione interessante. Se registriamo una normale nota vocale dentro WhatsApp, l'app deve necessariamente ricevere l'audio in chiaro prima di codificarlo e cifrarlo, quindi il nostro secondo layer non esiste più nel punto che ci interessa.

Per ottenere E2EE² anche sulla voce bisogna registrare l'audio dentro la companion app, codificarlo localmente, per esempio in Opus, cifrare il flusso e inviare il file risultante attraverso WhatsApp come documento. Il destinatario lo ascolta nella companion app dopo la decifratura.

È meno elegante della nota vocale nativa, ma molto più coerente con la separazione di fiducia che stiamo costruendo.

E le chiamate vocali?

Qui il salto di complessità diventa molto maggiore. Cifrare nuovamente una chiamata WhatsApp in tempo reale senza modificare il client richiederebbe intercettare e reiniettare audio a livello di sistema, un percorso che Android limita fortemente proprio per ragioni di privacy e sicurezza e che trasformerebbe rapidamente il progetto in qualcosa di invasivo. Non lo considererei quindi una naturale estensione della prima versione.

Per la voce asincrona, cioè messaggi audio, il file cifrato è pulito e semplice. Per una vera telefonata E2EE² costruirei direttamente un canale VoIP controllato dalla companion app invece di tentare di infilare un secondo codec cifrato dentro una chiamata WhatsApp già in corso.

Possiamo proteggere la chiave anche dall'applicazione stessa

Android Keystore rende possibile mantenere il materiale delle chiavi fuori dalla memoria ordinaria dell'applicazione e, sui dispositivi compatibili, utilizzare TEE oppure StrongBox per l'isolamento hardware. StrongBox possiede CPU, storage sicuro e generatore casuale propri e Android permette inoltre di vincolare l'uso della chiave all'autenticazione dell'utente.

Questo crea una modalità molto interessante: la chiave lunga della sessione può essere conservata cifrata e sbloccata soltanto dopo biometria oppure PIN del dispositivo, così rubare fisicamente un telefono bloccato non significa automaticamente poter aprire tutti i messaggi E2EE² salvati dentro WhatsApp.

Anche qui non parlerei di invulnerabilità. Se il dispositivo viene compromesso mentre l'utente è autenticato e sta leggendo il messaggio, l'attaccante può puntare al plaintext nel momento nel quale deve necessariamente essere mostrato. La crittografia protegge soprattutto il dato a riposo e durante il trasporto, non può impedire che il destinatario legittimo debba prima o poi trasformarlo nuovamente in informazione comprensibile.

Un protocollo riconoscibile permette di evolvere senza rompere tutto

Metterei all'inizio di ogni messaggio un header minimo come:

text

E2X1:

dove E2X identifica il nostro protocollo e 1 la versione. Il resto potrebbe contenere in forma codificata identificatore della sessione, contatore, nonce quando richiesto dal primitive scelto e ciphertext autenticato.

Questo permette in futuro di introdurre E2X2 con Double Ratchet, supporto multi-device oppure chiavi post-quantum senza rendere indecifrabili tutti i messaggi precedenti. La versione deve essere parte dei dati autenticati, così un aggressore non può semplicemente cambiare E2X2 in E2X1 nel tentativo di forzare un downgrade.

Anche replay e cross-chat devono essere pensati fin dall'inizio. Un messaggio valido per Mario non dovrebbe poter essere copiato nella sessione di Anna e risultare ugualmente valido. Per questo userei come associated data almeno versione, identificatore della sessione, direzione e contatore, facendo attenzione che l'IME non tenti di ricavare il destinatario leggendo l'interfaccia di WhatsApp ma utilizzi quello selezionato esplicitamente dall'utente.

Dove sta davvero il vantaggio rispetto alla E2EE che abbiamo già

WhatsApp dichiara che messaggi personali, chiamate, foto e video sono già protetti end-to-end e quindi il server non dispone normalmente delle chiavi necessarie per leggerne il contenuto. Il secondo layer non nasce allora per correggere una assenza di cifratura di rete, ma per restringere ulteriormente il trust boundary.

Con E2EE² posso decidere che la mia applicazione di messaggistica riceva soltanto ciphertext anche SUL MIO TELEFONO. Questo può avere valore quando voglio che esportazioni, database locali, backup e strumenti che lavorano sopra WhatsApp vedano soltanto dati cifrati da una chiave che vive fuori da WhatsApp.

In compenso perdo parecchie comodità. WhatsApp non potrà indicizzare il testo, mostrare anteprime intelligenti, cercare una parola all'interno del messaggio E2X, creare automaticamente preview di link cifrati oppure capire che un determinato contenuto è una fotografia. Anche citazioni e copia del testo diventano meno naturali. È il prezzo inevitabile della compartmentalization.

Cosa NON protegge E2EE²

Non nasconde mittente e destinatario a WhatsApp, non nasconde quando abbiamo scritto, non nasconde completamente le dimensioni dei messaggi, non impedisce ad un destinatario di fare una fotografia allo schermo con un secondo telefono e non salva un dispositivo già controllato da malware con privilegi sufficienti.

Non protegge nemmeno da una chiave condivisa male. Se i due utenti si scambiano il seed attraverso lo stesso account già compromesso e non verificano nulla, abbiamo semplicemente costruito un'altra cifratura sopra un'identità che potrebbe essere già stata sostituita.

E non dobbiamo raccontarci che “doppio cifrato” significhi automaticamente “doppio sicuro”. Il vero aumento della sicurezza deriva dall'indipendenza delle chiavi e dei componenti, non dal numero di lucchetti disegnati sulla schermata.

Per una prima versione Android farei molto meno di quanto si potrebbe fare

La versione iniziale che costruirei avrebbe soltanto quattro componenti: una tastiera offline che cifra prima di effettuare il commit, una companion app capace di decifrare esplicitamente i pacchetti E2X, un sistema di pairing tramite QR code e Android Keystore per proteggere le chiavi. Niente AccessibilityService, niente overlay sopra WhatsApp, niente hooking, niente root e nessun tentativo di leggere automaticamente tutte le notifiche.

Questa architettura è meno spettacolare di una chat nella quale tutto si decifra magicamente dentro la bolla originale, ma è molto più coerente con l'obiettivo di sicurezza perché ogni permesso che eliminiamo è una strada in meno che un attaccante può utilizzare.

La seconda versione aggiungerebbe Streaming AEAD per file, fotografie e audio, mentre la terza potrebbe introdurre un vero ratchet per forward secrecy e multi-device.

Solo dopo penserei alla comodità.

Ed è proprio questo che rende interessante l'esperimento

La parte più curiosa è che non serve modificare WhatsApp. Non serve conoscere le sue chiavi, non serve violare il Signal Protocol e non serve costruire una infrastruttura di messaggistica alternativa. Utilizziamo WhatsApp esattamente per ciò che sa fare molto bene, cioè consegnare contenuti fra due persone attraverso un proprio canale già cifrato, ma decidiamo che il contenuto affidato a quel canale sia già stato reso opaco da un secondo sistema del quale controlliamo interamente le chiavi.

Il concetto è estendibile praticamente a qualsiasi applicazione che accetti testo o file perché il punto di cifratura non appartiene al messenger, appartiene all'utente. Cambiamo WhatsApp con Telegram, SMS, email o una piattaforma aziendale ed il pacchetto E2X continua ad essere soltanto una sequenza di caratteri oppure un file.

Per questo considero E2EE² più interessante come ARCHITETTURA che come semplice esercizio crittografico. Non stiamo aggiungendo un altro lucchetto allo stesso server, stiamo spostando il confine del plaintext un passo più vicino alla persona, facendo in modo che il messaggio nasca cifrato prima di entrare nell'app che lo trasporterà e torni leggibile soltanto in un componente separato posseduto dal destinatario.

La vera sfida non è riuscire a cifrare una frase, perché quello oggi è quasi banale. La sfida è farlo senza trasformare la tastiera in un keylogger, senza inventare algoritmi deboli, senza lasciare chiavi e plaintext sparsi negli appunti e nello storage e senza promettere una sicurezza che il sistema operativo compromesso non può garantire.

Se risolviamo bene questi punti, il risultato diventa effettivamente qualcosa di interessante: WhatsApp continua ad avere la propria E2EE, mentre sopra di essa viaggia una conversazione che per WhatsApp stesso è soltanto rumore autenticato.