Il web post-quantum non si ferma a TLS: il problema delle credenziali anonime

Avere una connessione HTTPS protetta con algoritmi post-quantum non significa avere un’applicazione pronta per il mondo post-quantum. Il trasporto è soltanto uno dei livelli in cui usiamo crittografia a chiave pubblica. Un altro, meno visibile ma decisivo per la gestione del traffico automatizzato, è la possibilità di verificare che un client abbia diritto a fare una richiesta senza trasformare quella verifica in un sistema di tracciamento.

È su questa differenza che si concentra la ricerca pubblicata da Cloudflare il 6 novembre 2026: costruire credenziali anonime che resistano a futuri attacchi quantistici. Non è un prodotto da attivare con un interruttore, né la dimostrazione che il problema sia risolto. È però un buon esempio di quanto la migrazione crittografica sia soprattutto un lavoro di architettura.

Una connessione cifrata non è un sistema di autorizzazione

Nella discussione sul post-quantum si parla spesso di TLS, algoritmi di scambio delle chiavi e protezione dei dati registrati oggi per essere decifrati domani. È un problema reale e relativamente circoscritto: negoziare chiavi sicure tra client e server, gestire compatibilità e aggiornare le librerie.

Un sito deve però anche decidere quante richieste accettare, da chi e a quali condizioni. Se usa soltanto account, cookie persistenti o fingerprinting, può ottenere controllo al prezzo di maggiore correlabilità delle visite. Se rinuncia a qualunque controllo, espone risorse e servizi agli abusi. La crittografia può offrire una terza strada: attestare un diritto d’accesso senza rivelare l’identità del titolare a ogni utilizzo.

Privacy Pass nasce proprio intorno a questa idea. Un soggetto emette token che il client può successivamente presentare; la presentazione non deve essere collegabile all’emissione. Non è anonimato universale: indirizzi IP, comportamento applicativo e altri identificatori possono comunque rivelare informazioni. È una proprietà precisa di un protocollo, non una promessa di invisibilità.

Due proprietà di sicurezza che non vanno confuse

Il punto più interessante dell’analisi di Cloudflare è la separazione tra impossibilità di falsificare un token e impossibilità di collegarlo al suo titolare. Gli schemi attuali di Privacy Pass usano anche primitive classiche come RSA e curve ellittiche: un avversario dotato di un computer quantistico crittograficamente rilevante potrebbe in futuro produrre token falsi e aggirare i meccanismi che dipendono dalla loro autenticità.

Secondo Cloudflare, invece, la proprietà di non collegabilità dei token Privacy Pass resta incondizionata: non dipende dalla difficoltà di un problema matematico che un computer quantistico possa risolvere. È una distinzione fondamentale. Una componente può mantenere la privacy mentre perde la capacità di impedire abusi.

Per un responsabile tecnico questo cambia il modo di fare inventario: non basta chiedersi se un sito supporti ML-KEM su HTTPS. Occorre identificare firme, attestazioni, token, credenziali e sistemi anti-abuso che dipendono ancora da assunzioni crittografiche classiche.

MOLE, VOLE e il prezzo della flessibilità

Cloudflare sta studiando una famiglia di meccanismi denominata MOLE per credenziali e attestazioni con proprietà di privacy. Nella ricerca pubblicata a novembre descrive due costruzioni candidate, VOLE-IHAT e VOLE-ACT, basate su crittografia multivariata e prove a conoscenza zero di tipo VOLE-in-the-Head.

Una prova a conoscenza zero consente di dimostrare di conoscere un’informazione segreta che soddisfa una certa relazione senza rivelare quella informazione. VOLE-in-the-Head è un modo di costruire queste prove usando correlazioni matematiche che il verificatore può controllare. Non serve che chi gestisce un sito implementi personalmente questi protocolli; serve capire perché una firma post-quantum standard non sia automaticamente sostituibile a ogni tipo di credenziale anonima.

I numeri pubblicati da Cloudflare danno la misura del compromesso. Nelle stime attuali, VOLE-IHAT richiede circa 5,6 KB per l’emissione e 6,5 KB per la presentazione; VOLE-ACT circa 5,4 KB per l’emissione e 12 KB per l’utilizzo. Le chiavi pubbliche UOV indicate sono di circa 46,6 KB. Sono stime di ricerca, non prestazioni garantite in produzione né misure indipendenti.

La dimensione di una singola credenziale potrebbe sembrare modesta. Moltiplicata per molte richieste, dispositivi mobili, reti lente e infrastrutture distribuite, diventa invece un parametro progettuale. Non si può giudicare il protocollo soltanto dalla correttezza matematica: bisogna capire quante volte si emette un token, quante volte lo si presenta e quali verifiche devono avvenire sul percorso critico di una richiesta.

Il vero lavoro comincia quando il protocollo funziona

Cloudflare suggerisce una direzione: ammortizzare una singola presentazione su più richieste, anziché eseguire una verifica costosa ogni volta. È ragionevole, ma sposta il problema su durata delle sessioni, revoca, abuso di credenziali riutilizzabili e correlabilità. Più si ottimizza il costo, più occorre definire con precisione quale informazione può essere conservata e per quanto tempo.

Ci sono almeno quattro domande operative da porsi prima di progettare un sistema simile. Qual è l’unità di rate limiting: utente, dispositivo, sessione o capacità anonima? Quanto traffico aggiunge il protocollo in condizioni realistiche? Come si reagisce a una credenziale compromessa senza introdurre identificatori persistenti? Che cosa accade quando un client non supporta il nuovo meccanismo?

Queste domande sono importanti anche per i servizi che ricevono traffico da agenti software. Un’automazione legittima e un abuso possono apparire simili se osservati soltanto come sequenze di richieste. La possibilità di distribuire capacità verificabili senza costruire un identificatore universale è interessante, ma non elimina il bisogno di policy, limiti e osservabilità.

Una proposta promettente non è ancora uno standard operativo

Cloudflare è esplicita su ciò che manca: prove formali di sicurezza delle costruzioni proposte e ulteriore crittoanalisi dei parametri UOV. I numeri possono cambiare. La comunità dovrà valutare se le ipotesi matematiche reggono e se le implementazioni siano robuste.

Questo limite non riduce il valore della ricerca. Evita, piuttosto, un errore frequente: confondere un prototipo tecnicamente interessante con una funzionalità pronta per infrastrutture che devono operare continuamente e resistere ad avversari reali.

La roadmap post-quantum di Cloudflare e gli strumenti di telemetria TLS mostrano che la migrazione del trasporto è già misurabile. La migrazione delle credenziali anonime è in una fase diversa. Non bisogna mettere sullo stesso piano la disponibilità di una connessione ibrida ML-KEM e la maturità di nuovi schemi di attestazione.

Cosa dovrebbe fare oggi chi progetta servizi web

La prima attività non è installare una libreria sperimentale. È mappare dove l’applicazione usa crittografia per funzioni diverse dalla cifratura del canale: login, firme, token, attestazioni, accesso anonimo, API e meccanismi anti-abuso.

Poi serve distinguere ciò che può essere aggiornato con primitive standardizzate da ciò che richiede riprogettazione. I costi di comunicazione, la gestione delle sessioni e la compatibilità con i client vanno considerati requisiti, non dettagli da risolvere a fine progetto.

La lezione è semplice: essere post-quantum non è una proprietà binaria di un sito. È una caratteristica di ogni protocollo, del suo modello di minaccia e dell’architettura che lo ospita. TLS è una parte importante del percorso, ma non può sostituire il lavoro necessario sugli altri livelli.