2026-08-18 · RICERCA · Il team di Offensive Technology

Certificate transparency post-quantum: il 43% dei log static-CT firma già con ML-DSA-44

La certificate transparency ha silenziosamente avviato la propria migrazione post-quantum, ed è già al 43% del percorso al livello di firma dei log. Abbiamo scaricato il file di checkpoint pubblico da ciascuno dei 70 log static-CT presenti nella lista pubblica dei log, e 30 di essi (42.9%) allegano una firma post-quantum ML-DSA-44 a ogni checkpoint, proprio accanto alla loro firma classica ECDSA. È un dato notevole, perché nessuna superficie comparabile si è mossa così: il DNSSEC è allo 0% post-quantum e l'handshake TLS sta solo iniziando. Il rovescio della medaglia è l'altra metà del design. Il livello dei witness, il meccanismo che dovrebbe cogliere un log che mente sulla propria storia, è appena distribuito: solo 11 log su 70 portano una qualche cosignature di witness, abbiamo osservato appena 6 witness distinti in tutto l'ecosistema, e 0 di essi sono post-quantum. La firma corre avanti rispetto al controllo.

Cosa abbiamo misurato, e perché un checkpoint è leggibile

La certificate transparency si sta spostando dal vecchio protocollo request-response RFC 6962 al formato static-ct-api, in cui un log è semplicemente un insieme di file statici su una CDN. Let's Encrypt ha spento i suoi log classici il 28 febbraio 2026 (il loro piano di fine vita ne riporta la tempistica), e il modello tiled è ormai lo standard. Il piccolo file che riassume lo stato corrente di un log statico è il suo checkpoint: il nome del log, la dimensione del suo albero, l'hash della radice Merkle, e poi un blocco di firme. È pubblico per progettazione, perché i monitor di tutto il mondo lo scaricano costantemente per tenere il log onesto. Leggerlo non tocca nulla di privato e non sonda alcun host; è la stessa GET che esegue un monitor, ed è l'equivalente CT della lettura di un record DNS pubblico.

Abbiamo preso la lista pubblica dei log CT, estratto ogni log tiled, e scaricato il checkpoint di ciascuno esattamente una volta. Tutti e 70 hanno risposto. Poi abbiamo analizzato il blocco delle firme. Nel formato signed-note usato da un checkpoint, ogni firma è su una riga propria: un marcatore a trattino, poi il nome del firmatario, poi un valore base64 che è un key hint di quattro byte seguito dalla firma stessa. Questo ultimo dettaglio è l'intero metodo: la lunghezza in byte della firma ne rivela l'algoritmo. Una firma Ed25519 è di 64 byte. La firma legacy tree-head di RFC 6962 è un timestamp più un breve blob ECDSA. E una firma ML-DSA-44 è di 2.420 byte, la dimensione fissa definita da NIST FIPS 204. Quindi non abbiamo dovuto fidarci di un'etichetta; abbiamo contato i byte.

Il post-quantum è già sul 43% dei log static-CT

Ecco l'intera popolazione, classificata in base a ciò che appare effettivamente in ogni checkpoint. Un singolo checkpoint porta di solito più di una riga di firma, quindi questi sono conteggi di log, non di firme.

La seconda riga è la notizia principale. Trenta log non si limitano a firmare il proprio checkpoint con una chiave classica; aggiungono sopra una firma ML-DSA-44 completa di 2.420 byte, così ogni checkpoint è firmato in entrambi i modi. È esattamente ciò che richiede la specifica del checkpoint. Nelle sue stesse parole, i log dovrebbero usare cosignature ML-DSA-44 per firmare il checkpoint, e il formato cosignature definisce un tipo post-quantum dedicato, descritto come sicuro contro i computer quantistici, posizionato proprio accanto a quello classico. Un tasso di adozione del 43% per un dovrebbero che la maggior parte degli operatori avrebbe potuto ignorare è un movimento rapido. Ed è concentrato: le firme post-quantum si raggruppano in una minoranza di operatori che gestiscono grandi famiglie di log a shard temporali, quindi una decisione presa da pochi team copre già quasi metà della popolazione. Riportiamo il dato aggregato invece di una lista con nomi e biasimo, perché firmare con più crittografia è un bene, non un rilievo negativo verso nessuno.

Il motivo per cui questo livello può muoversi mentre altri no è la dimensione. Una firma ML-DSA-44 è circa 38 volte più grande di una ECDSA, motivo per cui non entra in un pacchetto DNS e per cui l'handshake TLS ne è cauto. Ma un checkpoint è un file minuscolo scaricato da poche migliaia di monitor, non un campo inviato su miliardi di handshake. Il livello di transparency ha il budget di byte per passare per primo al post-quantum, e lo sta spendendo.

Il livello dei witness è la storia opposta

Firmare un checkpoint dimostra che il log ha fatto una dichiarazione. Non dimostra che il log abbia fatto la stessa dichiarazione a tutti. Un log compromesso può mettere in atto un attacco split-view: mostrare alle vittime un albero che contiene un certificato fraudolento, e mostrare ai monitor un albero pulito che non lo contiene, così la frode non finisce mai dove qualcuno sta effettuando audit. La soluzione è il witnessing. Un witness è un servizio indipendente che ricorda l'ultimo checkpoint visto da un log, verifica che ogni nuovo checkpoint sia un'estensione coerente e append-only, e solo allora restituisce una cosignature. Richiedendo un numero sufficiente di witness indipendenti su un checkpoint, un log non può più mantenere due storie, perché nessun witness onesto ne co-firmerà entrambe.

È il meccanismo che trasforma un log da fidati-di-me a non-può-mentire. Nell'ecosistema reale, è esile:

• Solo 11 log su 70 (16%) portano una qualche cosignature di witness, e ognuno di questi log appartiene alla famiglia di log di un unico operatore. I checkpoint di ogni altro operatore sono firmati dal solo log, senza alcuna parte indipendente che ne attesti la coerenza.
• In tutto l'ecosistema compaiono appena 6 witness distinti, e solo 2 di essi sembrano servizi di produzione. Gli altri quattro si identificano come witness di staging, dev o proof-of-concept.
• Ogni singola cosignature di witness è Ed25519 classico. Nessun witness usa il tipo di cosignature post-quantum ML-DSA-44 definito dalla stessa specifica. Il livello anti-equivocazione è allo 0% post-quantum.

Dove il witnessing funziona, funziona bene: le cosignature che abbiamo osservato portavano timestamp con una mediana di circa 5 secondi rispetto al nostro fetch, quindi i witness co-firmano quasi in tempo reale. Il problema non è la latenza, è la copertura. Una difesa split-view che copre un solo operatore e conta due partecipanti in produzione è un pilota promettente, non ancora una garanzia a livello di ecosistema.

Due scommesse diverse sul futuro della transparency

Mettendo i due livelli fianco a fianco emerge uno schema più interessante di ciascun numero preso da solo. I log che sono passati al post-quantum e i log che portano cosignature di witness sono insiemi disgiunti, gestiti da operatori diversi. Un gruppo sta investendo il proprio sforzo sulle firme post-quantum dei log e non implementa il witnessing. L'altro gruppo sta investendo il proprio sforzo sulla rete di witness e non implementa la firma post-quantum. Nessuno in questo censimento fa entrambe le cose.

Vale la pena nominare questa divisione perché i due investimenti difendono da minacce diverse, e la minaccia più difficile è quella che si perde. La firma post-quantum difende dallo scenario di un futuro remoto in cui un computer quantistico falsifica la firma di un log. Il witnessing difende dallo scenario presente in cui un log equivoca oggi. L'ecosistema ha collettivamente anticipato la minaccia speculativa e sotto-investito in quella concreta. Il post-quantum è l'upgrade visibile e dimostrabile; il witnessing richiede che altre persone gestiscano infrastrutture e che i client pretendano un quorum, il che è organizzativamente più difficile. Così la metà facile è arrivata per prima.

Le firme decoy, e perché sono un buon segnale

Un rilievo incidentale dice qualcosa di positivo sull'ecosistema. Su 46 dei 70 log (66%), il checkpoint porta una riga di firma sotto il nome grease.invalid, i cui byte sono casuali e non verificano contro nulla. Questo non è previsto dalla specifica, quindi lo riportiamo come osservazione, non come regola. Ma corrisponde esattamente al requisito documentato secondo cui un verificatore deve ignorare le firme provenienti da chiavi che non riconosce. È questa regola che rende sicuro per un log aggiungere cosignature di witness o una nuova chiave post-quantum senza rompere i client esistenti. Emettere una firma deliberatamente non valida, sullo stile della tecnica GREASE del TLS, costringe ogni parser a rispettare davvero quella regola del must-ignore invece di bloccarsi alla prima riga sconosciuta. Due terzi dei log che sottopongono a stress test i propri consumer è un segno di un ecosistema che si aspetta che il blocco di firme continui a crescere, ed è esattamente ciò di cui ha bisogno una transizione post-quantum.

Come lo abbiamo misurato, così uno scettico può fidarsi dei numeri

Il dataset è nostro, costruito unicamente da file pubblici, e riportato in forma aggregata. Non abbiamo scansionato, sondato, inviato dati a, né ci siamo connessi ad alcun log oltre a scaricare l'unico file di checkpoint pubblico che ciascuno pubblica esattamente per questo scopo. In un checkpoint non esiste alcun dato privato; è una dimensione dell'albero, un hash, e delle firme. Non nominiamo alcun operatore come carente, perché nessuno lo è: questa è un'istantanea di un ecosistema a metà del suo aggiornamento.

• La popolazione. Ogni log tiled nella lista pubblica dei log CT, 70 in tutto. Tutti e 70 hanno restituito un checkpoint analizzabile alla data della misurazione. Molti sono shard temporali, quindi il numero di log è maggiore del numero di operatori.
• La classificazione. Per ogni riga di firma abbiamo decodificato il base64, scartato il key hint di quattro byte, e letto la lunghezza restante. 2.420 byte (in una busta con timestamp) è una firma ML-DSA-44 secondo FIPS 204; 64 è Ed25519; il breve blob con timestamp è la firma tree-head di RFC 6962. Algoritmo per costruzione, non per etichetta.
• Log contro witness. Una firma il cui nome corrisponde all'origine del log stesso è il log che firma se stesso. Una cosignature sotto un'identità di witness separata è un'attestazione indipendente. Le abbiamo contate separatamente, motivo per cui il conteggio post-quantum e il conteggio dei witness descrivono livelli diversi.
• Post-quantum per dimensione. I 30 log post-quantum portano ciascuno una firma esattamente della lunghezza ML-DSA-44, nella busta di cosignature definita dalla specifica per essa. Uno schema classico non può produrre accidentalmente una firma di 2.420 byte, quindi il conteggio non è una stima.

Perché è importante, e i limiti onesti

La certificate transparency è un fondamento su cui poggiano altre difese. È il modo in cui il mondo si accorge di un certificato emesso in modo errato per una banca o un provider di posta, e sostiene controlli come le garanzie leggibili da un certificato e restrizioni all'emissione come CAA. Come il DNSSEC, la CT firma anziché cifrare, quindi il rischio quantico riguarda la falsificazione futura, non l'harvest-now-decrypt-later. Ciò significa che il risultato del 43% post-quantum è genuinamente in anticipo sulla minaccia, il che è una buona notizia, rara. Ma il rovescio della medaglia è la parte che dovrebbe ricevere più attenzione: il meccanismo che rende un log affidabile contro un attaccante presente, non quantico, il witnessing indipendente, è quello esile e classico. Se si sta scommettendo sulla transparency per cogliere la prossima emissione errata, la rete di witness è il numero da tenere d'occhio, non l'algoritmo di firma.

Un risultato senza i propri limiti è marketing, quindi ecco i confini.

• Una lista, un giorno. Questa è la lista pubblica dei log a una data singola. Gli shard vengono aggiunti e ruotati, e il witnessing è in fase di distribuzione attiva, quindi i conteggi esatti si sposteranno. Il rilievo strutturale, ossia che la firma ha superato il witnessing, è la parte duratura.
• Solo i checkpoint serviti. Abbiamo letto ciò che ogni log serve al proprio endpoint di checkpoint. Un witness che co-firma un log ma distribuisce le proprie cosignature altrove non comparirebbe qui, quindi la quantità reale di attività di witnessing è un minimo, non un massimo. Resta valido il punto che i checkpoint effettivamente scaricati dai client sono per lo più privi di witness.
• Presenza, non verifica. Abbiamo classificato le firme per algoritmo e identità, non verificandone crittograficamente ciascuna rispetto alla propria chiave. Una firma ML-DSA-44 presente e della dimensione corretta è una forte evidenza di firma post-quantum; confermare che ogni firma sia valida è un esercizio separato.
• La riga GREASE è dedotta. La decoy grease.invalid è la nostra lettura di un comportamento non documentato ma coerente, non una funzionalità imposta dalla specifica.

Domande frequenti

Cos'è un log CT statico?

Un log CT statico è un log di certificate transparency servito come file statici, chiamati tile, da uno storage a oggetti o una CDN, seguendo la specifica C2SP static-ct-api. Invece dell'API request-response di RFC 6962, pubblica tile append-only da 256 voci più un piccolo checkpoint firmato che indica la dimensione corrente dell'albero e l'hash radice. I monitor leggono i file direttamente, il che rende i log economici da gestire e replicare. Questo design, inizialmente chiamato Sunlight API, è diventato mainstream tra gli operatori CT nel 2025 e nel 2026.

I log di certificate transparency sono già post-quantum?

In parte, e prima di quanto la maggior parte delle persone presuma. Nel nostro censimento di tutti i 70 log static-CT, 30 di essi (43%) allegano già una firma ML-DSA-44 a ogni checkpoint, accanto alla loro firma classica. ML-DSA-44 è lo schema reticolare FIPS 204 che resiste agli attacchi quantistici, ed è ciò che la specifica del checkpoint raccomanda. Quindi il livello di firma dei log è ben avviato nella sua migrazione post-quantum. Il livello dei witness che co-firma quei checkpoint è invece ancora allo 0% post-quantum; ogni cosignature di witness osservata era Ed25519 classico.

Cos'è ML-DSA-44 e perché viene usato qui?

ML-DSA-44 è il set di parametri più piccolo di ML-DSA, lo standard di firma a reticolo modulare definito in NIST FIPS 204, derivato da CRYSTALS-Dilithium. Le sue firme sono di 2.420 byte e le sue chiavi di 1.312 byte, molto più grandi di una firma Ed25519 di 64 byte, ma non viene infranto dall'algoritmo di Shor. La certificate transparency può assorbire questa dimensione perché un checkpoint viene scaricato occasionalmente dai monitor, non inviato a ogni handshake, motivo per cui la CT può adottare firme post-quantum anni prima del DNSSEC o dell'handshake TLS.

Cos'è un witness CT e una cosignature di witness?

Un witness è un servizio indipendente, identificato da un nome e una chiave pubblica, che osserva i checkpoint di un log. Prima di co-firmare un nuovo checkpoint verifica che il nuovo albero sia coerente con l'ultimo visto, il che significa che il log ha solo aggiunto dati e non ha mai riscritto la propria storia, poi restituisce una cosignature con timestamp definita dalle specifiche C2SP tlog-witness e tlog-cosignature. Un checkpoint che porta cosignature da più witness indipendenti è molto più difficile da falsificare per un log compromesso.

Come previene una split view una cosignature di witness?

Un attacco split-view è un log che mostra un albero alle vittime e un albero diverso, onesto, ai monitor, così i certificati fraudolenti non compaiono mai dove qualcuno effettua audit. Poiché un witness co-firma solo dopo aver verificato la coerenza con la storia già in suo possesso, un log non può far co-firmare due checkpoint contraddittori dallo stesso witness onesto. Se i client richiedono cosignature da un quorum di witness indipendenti, il log deve mostrare a tutti lo stesso albero append-only, il che chiude la falla che il semplice logging lascia aperta.

Quando sono stati spenti i log di certificate transparency RFC 6962?

La migrazione si è svolta nel 2025 e nel 2026. Let's Encrypt ha annunciato la fine del ciclo di vita dei propri log RFC 6962 nell'agosto 2025, li ha resi di sola lettura il 30 novembre 2025, e li ha spenti completamente il 28 febbraio 2026, a favore dei suoi log statici Sycamore e Willow. Chrome ha aggiunto il supporto a static-ct-api all'inizio del 2025 e sta eliminando gradualmente il requisito che almeno un SCT provenga da un vecchio log RFC 6962.

Quanti log di certificate transparency esistono nel 2026?

La lista pubblica dei log CT che abbiamo usato contiene 70 log statici, tiled, distribuiti su una manciata di operatori, oltre ai restanti log classici. Molti dei 70 sono shard temporali, ciascuno che copre un intervallo di date di scadenza dei certificati, quindi un singolo operatore ne gestisce diversi contemporaneamente. Tutti e 70 i log statici hanno servito un checkpoint leggibile al momento della misurazione.

Letture correlate

• DNSSEC post-quantum readiness: lo 0% dei primi 30.000 domini. La stessa domanda post-quantum su una superficie che non può ancora muoversi, perché le firme non entrano in un pacchetto DNS.
• Il FIPS disabilita il TLS post-quantum? La transizione post-quantum misurata sull'handshake TLS invece che sul livello di transparency.
• Cosa dimostrano i certificati. Leggere le garanzie crittografiche dai record pubblici invece di fidarsi dell'etichetta, lo stesso metodo applicato ai certificati stessi.
• Quanti domini principali limitano l'emissione dei certificati? L'ecosistema dei certificati misurato passivamente da dati pubblici.