I computer quantistici stanno spingendo chi si occupa di sicurezza online a ripensare le fondamenta della rete, e Let’s Encrypt ha deciso di muoversi per prima. L’autorità di certificazione che distribuisce gratuitamente i certificati per le connessioni cifrate ha messo sul tavolo una delle proposte più ambiziose di sempre per il futuro della PKI pubblica: i cosiddetti Merkle Tree Certificates, una struttura pensata per reggere agli attacchi di una nuova generazione di macchine. La posta in gioco è alta, perché la sicurezza di miliardi di connessioni quotidiane poggia su un equilibrio fragile fatto di crittografia solida, certificati affidabili e procedure che devono funzionare senza intoppi.
Per anni la discussione sulla crittografia post-quantum si è concentrata quasi solo sulla protezione dei dati cifrati. Lo schema è noto: un malintenzionato intercetta oggi le comunicazioni HTTPS, le conserva e aspetta il giorno in cui un computer quantistico sarà capace di decifrarle. È l’approccio chiamato harvest now, decrypt later. L’autenticazione, invece, sembrava un problema meno pressante, dato che per falsificare un certificato TLS serve generare firme valide in tempo reale, cosa fattibile solo quando arriveranno sistemi quantistici davvero potenti. Ma le carte in tavola si stanno rimescolando in fretta.
Perché la minaccia non riguarda più solo la cifratura
Le linee guida governative statunitensi CNSA 2.0 e le bozze pubblicate dal NIST prevedono di mandare in pensione algoritmi come RSA-2048 e P-256 entro il 2035. Anche l’Unione Europea ha fissato obiettivi simili per le infrastrutture critiche e i sistemi ad alto rischio. Qualcuno poi ha accelerato parecchio: Google punta a completare la migrazione interna entro il 2029, e Cloudflare ha preso un impegno analogo. Nel frattempo il linguaggio Go, con la versione 1.27, ha aggiunto il supporto nativo a ML-DSA, uno degli algoritmi di firma post-quantum standardizzati dal NIST.
Sostituire gli algoritmi attuali con versioni resistenti ai computer quantistici sembra semplice, ma nella pratica salta fuori un problema scomodo. Le firme post-quantum sono molto più ingombranti. Giusto per dare un’idea: una firma ML-DSA-44 occupa circa 2.420 byte, mentre una ECDSA P-256 se la cava con appena 64 byte e una RSA-2048 ne usa 256. Anche le chiavi pubbliche si gonfiano: oltre 1.300 byte per ML-DSA-44 contro le poche decine o centinaia di byte degli algoritmi tradizionali. Una normale connessione TLS contiene più firme e diverse chiavi lungo la catena di certificazione, quindi rimpiazzare ogni pezzo con un equivalente post-quantum porterebbe l’handshake oltre i 10 KB. Sembra poco, eppure studi di Cloudflare mostrano che handshake più pesanti causano rallentamenti e fanno aumentare le connessioni che falliscono su reti mobili, collegamenti instabili o infrastrutture vecchie. E il web pubblico campa di compatibilità: basta penalizzare anche una piccola fetta di utenti per frenare l’adozione.
Come funzionano i Merkle Tree Certificates
Qui entra in gioco l’idea sostenuta da Let’s Encrypt, che ribalta il modo in cui i certificati vengono emessi. Invece di firmare uno per uno ogni certificato X.509, l’autorità genera grandi gruppi di certificati e li sistema dentro un Merkle Tree, una struttura crittografica già diffusa in tanti sistemi di verifica dell’integrità. Una sola firma copre l’intero gruppo. I browser tengono aggiornati a parte i riferimenti per verificare queste strutture, chiamati landmarks, così durante l’handshake non serve più trasmettere tutta la catena tradizionale.
Il client riceve una firma, una chiave pubblica e una prova di inclusione nel Merkle Tree. Il bello è che, pur usando algoritmi post-quantum, i dati trasferiti possono risultare addirittura inferiori rispetto alle infrastrutture TLS classiche. Esiste anche una modalità standalone per i casi in cui il browser non abbia informazioni aggiornate sui landmarks: lì l’handshake cresce un po’, ma resta su dimensioni gestibili. Chrome e Cloudflare stanno già provando gli MTC su traffico reale, mentre il gruppo di lavoro PLANTS dell’IETF lavora alle specifiche per la standardizzazione. Chrome, tra l’altro, ha indicato pubblicamente i Merkle Tree Certificates come la strada preferita per portare i certificati post-quantum sul web pubblico.
Le tempistiche e cosa cambia per chi usa Let’s Encrypt
L’organizzazione ha fissato la seconda metà del 2026 come traguardo per un ambiente di test in grado di emettere Merkle Tree Certificates. Una piattaforma pronta per la produzione, invece, dovrebbe arrivare nel corso del 2027. Dietro queste date c’è un lavoro enorme: modificare l’infrastruttura di emissione, aggiornare il protocollo ACME, ridisegnare i meccanismi di revoca e integrare nuove funzioni nelle componenti che gestiscono i log di trasparenza. Non un semplice aggiornamento software, ma una revisione profonda di una delle infrastrutture più usate dell’intera Internet pubblica.
Per chi usa Let’s Encrypt oggi non cambia niente: i certificati attuali continuano a essere emessi e rinnovati come sempre. La transizione verso la crittografia post-quantum, però, va preparata con anticipo. Gli operatori farebbero bene a verificare già adesso il supporto agli schemi di scambio chiavi ibridi come X25519MLKEM768, considerati tra le misure più efficaci contro gli attacchi harvest now, decrypt later. Browser moderni e sistemi operativi recenti queste tecnologie le supportano già: spesso manca solo l’abilitazione lato server.