PQC StatusHarvest now, decrypt later (HNDL, «raccogli ora, decifra dopo») è un attacco paziente: si cattura oggi il traffico cifrato, lo si conserva e lo si decifra anni dopo, quando l'accordo di chiave che lo proteggeva non regge più. Oggi non richiede alcun computer quantistico, solo capacità di intercettazione e spazio su disco. La domanda utile per un team di sicurezza non è quindi quando esisterà un computer quantistico crittograficamente rilevante, ma per quanto tempo ciascun flusso di dati deve restare riservato, e quali sistemi trasportano i flussi con la durata più lunga.
Il modello di minaccia, formulato con precisione
Conviene scomporre l'avversario in due capacità distinte, separate nel tempo.
- Oggi: la raccolta. Intercettazione passiva su un network tap, presso un provider di transito a monte, in un punto di peering, su un load balancer o un middlebox compromesso, oppure il furto di un archivio di sessioni già registrate. Il testo cifrato viene conservato, non letto.
- Dopo: il calcolo. Il recupero di una chiave privata a partire da una chiave pubblica. L'algoritmo di Shor, su un computer quantistico sufficientemente grande, rompe RSA, ECDH, Diffie-Hellman su campi finiti, ECDSA, EdDSA e DSA, qualunque sia la dimensione della chiave. Passare da RSA-2048 a RSA-4096, o da una curva ellittica a una più grande, non cambia nulla.
La crittografia simmetrica si comporta diversamente. AES, SHA-2 e SHA-3 non sono rotti da Shor. L'algoritmo di Grover offre un vantaggio minore, quadratico, contro le chiavi simmetriche, ed è per questo che AES-256 è preferibile quando i dati devono restare riservati a lungo. Una sessione registrata non è a rischio perché AES-GCM ha protetto il payload. È a rischio per il modo in cui la chiave AES è stata concordata.
La forward secrecy non risolve il problema
TLS 1.3 utilizza sempre un accordo di chiave effimero, in pratica ECDH su X25519 o su una curva NIST. La forward secrecy significa che il furto, domani, della chiave privata a lungo termine del server non rivela le sessioni di ieri, perché il segreto di sessione deriva da componenti effimere. Ma queste componenti pubbliche effimere viaggiano in chiaro all'interno dell'handshake. Un handshake registrato contiene quindi tutto ciò che serve per ricostruire il segreto di sessione, per chiunque sia in grado di risolvere quella singola istanza di accordo di chiave. La forward secrecy protegge dal furto delle chiavi. Non protegge dalla crittoanalisi futura dell'accordo di chiave stesso. In questo divario sta l'intero problema HNDL.
Perché lo scambio di chiavi si migra per primo e le firme dopo
Una firma viene verificata al momento della connessione. Se un algoritmo di firma diventa falsificabile tra dieci anni, ciò non consente a nessuno di leggere una sessione registrata oggi: le chiavi di sessione non sono mai state derivate dal certificato. Ciò che una firma compromessa consente è l'impersonificazione in futuro, e artefatti contraffatti che restano considerati attendibili a lungo.
Da qui l'ordine seguito da tutte le roadmap ufficiali. Viene prima l'accordo di chiave ibrido post-quantistico, basato su ML-KEM, il meccanismo di incapsulamento di chiave (KEM) standardizzato come NIST FIPS 203 il 13 agosto 2024 (FIPS 203). Seguono le firme post-quantistiche come ML-DSA (FIPS 204), per le catene di certificati. I gruppi TLS ibridi X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024 figurano nel registro IANA dei parametri TLS, e la RFC 10024 (agosto 2026) specifica l'accordo di chiave ibrido post-quantistico e tradizionale (PQ/T) per TLS 1.3. Le versioni attuali di Chrome, Edge e Firefox offrono X25519MLKEM768 per impostazione predefinita: per molti endpoint pubblici si tratta quindi di una modifica di configurazione più che di un progetto.
Dopo non significa mai, e due categorie di firme meritano comunque un'attenzione precoce:
- Le firme la cui verifica deve restare attendibile a lungo: firma di firmware e aggiornamenti software, radici di fiducia del secure boot, firme di archivi e documenti, marcatura temporale.
- Certificati e credenziali con validità lunga, la cui riemissione è costosa o fisicamente complicata: prodotti embedded, apparecchiature industriali, smart card.
NSA CNSA 2.0, che si applica ai National Security Systems statunitensi, riflette questa distinzione. Prevede l'uso esclusivo di ML-KEM-1024 e ML-DSA-87 entro la fine del 2030 per la firma di software e firmware e per le apparecchiature di rete tradizionali, ed entro la fine del 2033 per browser e server web, servizi cloud e sistemi operativi.
Quali dati hanno una durata di riservatezza abbastanza lunga da contare
La durata di riservatezza è il periodo durante il quale una divulgazione causerebbe ancora un danno. È una proprietà aziendale e giuridica dei dati, non una proprietà del protocollo, ed è l'unico parametro della prioritizzazione HNDL che controllate interamente. Per iniziare bastano gli ordini di grandezza.
| Categoria di dati | Perché la durata è lunga o breve | Ordine di grandezza |
|---|---|---|
| Dati sanitari, genomici e biometrici | Identificano una persona per tutta la vita e non possono essere riemessi | Decenni |
| Materiale governativo, della difesa e diplomatico | I periodi di classificazione sono fissati dalle politiche, non dalla tecnologia | Decenni |
| Segreti industriali, formule, progetti, codice sorgente | Il valore segue il ciclo di vita della linea di prodotto | Da anni a decenni |
| Documenti coperti da segreto professionale, fascicoli di contenzioso, materiale del consiglio di amministrazione e delle operazioni straordinarie | Restano sensibili a lungo dopo la chiusura dell'operazione o del caso | Da anni a decenni |
| Credenziali e materiale crittografico in transito | Ereditano la durata di ciò che permettono di sbloccare | Anni |
| Dati personali conservati in base a obblighi di conservazione | Il danno persiste finché esistono i record | Anni |
| Prezzi in tempo reale, token di sessione brevi, telemetria operativa | Il valore decade rapidamente dopo la cattura | Da giorni a mesi |
Due correzioni di cui la maggior parte degli inventari ha bisogno. Primo, i dati a vita breve all'interno di un tunnel a vita lunga ereditano la durata del tunnel: un collegamento site-to-site che trasporta anche la replica di un database ha la durata del database. Secondo, i segreti in transito hanno la durata dei sistemi che aprono, non quella della richiesta che li ha trasportati.
Come classificare i sistemi in base alla durata dei dati
Per ciascun sistema, annotate due numeri. X è la durata di riservatezza dei dati che trasporta. Y è il tempo che richiederebbe realisticamente la migrazione di quel sistema, compresi compatibilità dei client, firmware delle appliance e finestre di modifica. Esiste una terza grandezza, il momento in cui il calcolo pertinente diventerà fattibile, e nessuno è in grado di indicarne una data credibile: trattatela quindi come sconosciuta. La regola praticabile è ciò che resta: ridurre Y, e investirlo prima dove X è più grande, perché il traffico già registrato non può essere richiamato.
| Livello | Criteri | Azione |
|---|---|---|
| Migrare ora | Durata di riservatezza superiore a circa dieci anni, oppure il flusso trasporta chiavi e credenziali, oppure attraversa reti che non controllate | Attivare l'accordo di chiave ibrido ML-KEM sul trasporto, preferire solo TLS 1.3, preferire AES-256 dove lo stack lo consente |
| Pianificare a seguire | Durata di pochi anni, traffico interno che transita comunque su reti di provider o partner | Agganciare la modifica al prossimo aggiornamento di piattaforma o appliance, attivare i gruppi ibridi man mano che i client li supportano |
| Seguire la piattaforma | Durata inferiore a un anno, nessun segreto né identificativo a lunga durata | Ereditare le impostazioni predefinite del sistema operativo, della libreria e del browser |
Questa classificazione ha bisogno di un inventario su cui poggiare. Il requisito 12.3.3 di PCI DSS v4.0.1, obbligatorio dal 31 marzo 2025, richiede già un inventario documentato delle cipher suite e dei protocolli in uso, riesaminato almeno ogni 12 mesi, con il monitoraggio della loro validità nel tempo. Le norme tecniche di regolamentazione DORA, Regolamento delegato della Commissione (EU) 2024/1774, richiedono all'articolo 6 una politica di cifratura che includa disposizioni per aggiornare o modificare la tecnologia crittografica in base agli sviluppi della crittoanalisi, e all'articolo 7 la gestione delle chiavi lungo l'intero ciclo di vita e un registro dei certificati per gli asset che supportano funzioni essenziali o importanti. L'articolo 21(2)(h) della NIS2 richiede politiche sull'uso della crittografia. Nessuno di questi testi menziona una colonna sulla durata dei dati: aggiungerne una all'inventario che già mantenete è una nostra interpretazione di un modo pratico per documentare la prioritizzazione, non un requisito letterale. Il presente articolo ha carattere informativo e non costituisce consulenza legale.
Cosa hanno in comune le tempistiche ufficiali
Le tempistiche pubblicate differiscono per natura e per formulazione, e le sfumature contano. La EU Coordinated Implementation Roadmap v1.1 (pubblicata il 23 giugno 2025) è un orientamento coordinato per gli Stati membri, non un regolamento vincolante per le imprese: primi passi, tra cui un inventario crittografico e roadmap nazionali, entro la fine del 2026, casi d'uso ad alto rischio migrati entro la fine del 2030, a rischio medio entro la fine del 2035. Le linee guida dell'NCSC britannico fissano la ricognizione e un piano iniziale entro il 2028, le migrazioni a massima priorità entro il 2031 e il completamento entro il 2035. BSI TR-02102-1 (versione 2026-01) è una linea guida tecnica: raccomanda l'accordo di chiave ibrido e considera accettabile l'accordo di chiave classico usato da solo soltanto fino alla fine del 2031, o fino alla fine del 2030 per esigenze di protezione molto elevate. NIST IR 8547 resta una bozza pubblica iniziale; propone di deprecare gli algoritmi vulnerabili ai computer quantistici con sicurezza a 112 bit dopo il 2030 e di vietare gli algoritmi a chiave pubblica vulnerabili ai computer quantistici dopo il 2035. ANSSI rende obbligatoria l'ibridazione nel proprio perimetro regolamentato e precisa che le sue raccomandazioni post-quantistiche non sono ancora obblighi normativi al di fuori di esso. La nostra pagina sulle scadenze della migrazione post-quantistica raccoglie in un unico punto il dettaglio delle date.
La struttura comune è più informativa di qualsiasi singola data: un gruppo a massima priorità intorno al 2030-2031, il resto entro il 2035, e un criterio di selezione per il primo gruppo che è essenzialmente la lunga durata dei dati. È l'argomento HNDL, recepito nelle politiche pubbliche.
Verificate cosa negoziano effettivamente i vostri handshake
Misurate prima di pianificare. Con OpenSSL 3.5 o successivo, la versione minima che fornisce i gruppi TLS ML-KEM, richiedete esplicitamente un gruppo ibrido e leggete cosa è stato negoziato:
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>&1 | grep -i groupPer gli accessi amministrativi, verificate l'accordo di chiave di una sessione SSH. OpenSSH 9.9 (19 settembre 2024) ha aggiunto mlkem768x25519-sha256, OpenSSH 10.0 (9 aprile 2025) lo ha reso l'accordo di chiave predefinito, e OpenSSH 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiave non post-quantistico, tramite WarnWeakCrypto, attivo per impostazione predefinita. Le note di rilascio sono pubblicate su openssh.com.
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | grep -i kexMettete il gruppo ibrido al primo posto e mantenete dietro di esso un fallback classico, ad esempio X25519MLKEM768 e poi X25519, così che i client meno recenti possano ancora connettersi. Eseguite i test in staging prima della produzione e tenete d'occhio la dimensione degli handshake sui collegamenti con banda limitata e sulle appliance che ispezionano il ClientHello.
Il prossimo passo
Iniziate dai due elementi che rendono meccanico tutto il resto: una colonna sulla durata dei dati aggiunta al vostro inventario crittografico, e una misura di ciò che i vostri endpoint esterni negoziano oggi. Per il secondo potete analizzare gratuitamente il vostro dominio con PQC Status: il report indica i gruppi ibridi ML-KEM offerti, le versioni TLS e le cipher suite, e la catena di certificati. Un'analisi descrive solo la configurazione TLS visibile dall'esterno: consideratela quindi come un elemento di evidenza per il vostro inventario, non come una certificazione né come un'attestazione di conformità. Poi prendete i sistemi del livello «migrare ora» e attivate su di essi l'accordo di chiave ibrido, in quest'ordine.