Un browser può eseguire crittografia robusta; bisogna comunque fidarsi del codice che gli viene distribuito.
Un browser può eseguire localmente la crittografia end-to-end, compresa l’instaurazione post-quantistica delle chiavi, senza installare un’app di messaggistica nativa. La domanda difficile non è se la matematica possa funzionare in una scheda. È se l’applicazione distribuita, la gestione delle chiavi e il percorso di aggiornamento meritino la fiducia richiesta dalla conversazione.
L’accesso via web può essere comodo quando non è possibile installare un’applicazione. Non rende l’app immune dalla censura, da un hosting compromesso, da estensioni dannose o da un dispositivo compromesso.
I componenti crittografici del browser
WebCrypto espone operazioni di basso livello per crittografia, derivazione delle chiavi, firma e gestione delle chiavi. Le implementazioni comuni forniscono primitive come AES-GCM ed ECDH. Queste operazioni sono componenti, non un protocollo completo di messaggistica autenticata.
Un’applicazione web può aggiungere un’implementazione di ML-KEM sottoposta a revisione, usando JavaScript o WebAssembly quando l’API nativa necessaria non è disponibile. Il supporto dei browser cambia: gli sviluppatori dovrebbero quindi verificare le funzionalità nelle esatte versioni di destinazione, senza presumere che ogni browser offra gli stessi algoritmi.
Un flusso ibrido concettuale è il seguente:
- Generare chiavi appropriate con casualità crittograficamente sicura.
- Autenticare il materiale di chiave dell’interlocutore tramite il meccanismo di identità del protocollo.
- Ottenere contributi classici e post-quantistici al segreto condiviso.
- Combinarli secondo lo schema di derivazione delle chiavi specificato e il contesto della conversazione.
- Usare le chiavi derivate per la cifratura autenticata, gestendo correttamente nonce e stato.
È uno schema esplicativo, non una ricetta di implementazione. FIPS 203 standardizza ML-KEM; non certifica una particolare applicazione per browser né definisce ogni passaggio di un protocollo di chat.
La distribuzione tramite HTTPS fa parte del modello di fiducia
Normalmente il server fornisce il JavaScript e il WebAssembly che elaboreranno il testo in chiaro. Un’applicazione modificata in modo malevolo può leggere un messaggio prima della cifratura o dopo la decifratura, anche se la sua libreria crittografica usa algoritmi validi.
HTTPS aiuta ad autenticare la distribuzione e a proteggerla dalle interferenze di rete. Non dimostra che il gestore dell’origine, il suo sistema di distribuzione o le sue dipendenze non siano compromessi. Una normale pagina HTTPS non è automaticamente un pacchetto applicativo firmato in modo indipendente.
Le considerazioni sulla sicurezza di WebCrypto del W3C trattano l’iniezione di script e la necessità di proteggere l’integrità dell’applicazione. Content Security Policy, una gestione attenta delle dipendenze e altri controlli di sicurezza web riducono i rischi, ma nessuno trasforma uno script arbitrario della stessa origine in un osservatore non attendibile incapace di toccare i dati dell’applicazione.
Anche WebAssembly condivide il confine di sicurezza dell’applicazione. La sua sandbox limita l’accesso all’host attraverso interfacce definite; non rende affidabile la pagina che lo richiama. Compilare C in Wasm non rende il linguaggio sorgente sicuro nella gestione della memoria.
Le chiavi non esistono necessariamente solo nella RAM
Un servizio di messaggistica nel browser può conservare chiavi o stato cifrato affinché l’utente ritrovi la stessa identità. Può anche offrire il collegamento di dispositivi o il recupero cifrato. Questi comportamenti devono essere documentati, non esclusi per supposizione.
Tra le domande utili figurano:
- Quali chiavi vengono conservate, e in quale archivio del browser?
- Che cosa succede quando si cancellano i dati del sito o termina una sessione di navigazione privata?
- Una chiave non estraibile è ancora utilizzabile da codice malevolo eseguito nel contesto dell’applicazione?
- Un aggiornamento appena distribuito può accedere al vecchio stato locale?
- Il recupero ripristina l’identità, la cronologia dei messaggi o entrambe?
Una chiave WebCrypto non estraibile limita l’esportazione tramite l’API. Da sola non impedisce a codice applicativo ostile di richiedere operazioni consentite o raccogliere testo in chiaro.
I client web e nativi comportano compromessi diversi
| Aspetto | Client nel browser | Client nativo |
|---|---|---|
| Distribuzione | Origine, hosting e processo di aggiornamento web | Store di app o distribuzione di pacchetti e processo di firma |
| Persistenza locale | Archiviazione del browser e comportamento del profilo | Archiviazione delle app del sistema operativo e ciclo di vita dell’applicazione |
| Esposizione | Script della stessa origine, estensioni e vulnerabilità del browser | Dipendenze dell’applicazione e vulnerabilità del sistema operativo o dell’app |
| Disponibilità | Dominio raggiungibile e servizi di rete necessari | Anche l’app installata ha bisogno dei servizi di rete richiesti |
Nessuna colonna determina un vincitore senza esaminare l’implementazione. Un’app web può restare accessibile dopo la rimozione da uno store, ma un dominio bloccato o un percorso di rete mancante possono comunque impedire l’accesso.
Misurare le prestazioni anziché prometterle
ML-KEM-768 usa una chiave di incapsulamento di 1.184 byte e un testo cifrato di 1.088 byte secondo FIPS 203. Queste dimensioni aiutano a spiegare perché i protocolli possono pianificare gli aggiornamenti KEM invece di allegare nuovo materiale a ogni messaggio breve. Non sono misurazioni della larghezza di banda o della velocità di un’intera applicazione.
Un benchmark utile specifica browser, dispositivo, build, metodo di riscaldamento, operazione misurata e distribuzione dei tempi. Occorre includere avvio della pagina, caricamento dei moduli, uso della memoria, dispositivi di fascia bassa e sovraccarico di rete. Affermazioni come «meno di due millisecondi su tutti i telefoni moderni» richiedono misurazioni pubblicate; questo articolo non le fornisce.
Applicare questi criteri a Livara
La panoramica sulla sicurezza di Livara documenta LVR1 e i limiti del suo recupero. Il suo Proof Lab dimostra alcune operazioni locali P-256, HKDF e AES-GCM; la pagina colloca esplicitamente la composizione completa LVR1/LGS1 fuori da quel banco di prova. Una dimostrazione riuscita, quindi, non prova la sicurezza di tutto il codice web distribuito.
Prima di una conversazione sensibile nel browser, usa un client autentico e mantenuto, consulta il modello di minaccia attuale, proteggi il profilo del browser e verifica l’interlocutore tramite la procedura supportata di controllo delle chiavi. Comodità e crittografia utile possono coesistere, purché il confine della distribuzione web rimanga parte della valutazione.
