RSA-2048 dopo il 2030: cosa propone la bozza NIST IR 8547

NIST IR 8547 è una bozza pubblica iniziale (initial public draft), pubblicata il 12 novembre 2024 e ancora allo stato di bozza a settembre 2026. Propone di deprecare dopo il 2030 gli algoritmi a chiave pubblica vulnerabili al calcolo quantistico con un livello di sicurezza di 112 bit, di cui RSA-2048 è l'esempio tipico, e di non consentire più dopo il 2035 alcun algoritmo a chiave pubblica vulnerabile al calcolo quantistico. Queste due date sono proposte contenute in una bozza, non requisiti NIST definitivi, anche se vengono spesso citate come se fossero già in vigore.

Che cos'è NIST IR 8547

NIST IR 8547 è stato pubblicato come bozza pubblica iniziale il 12 novembre 2024 (csrc.nist.gov/pubs/ir/8547/ipd). Una bozza pubblica iniziale è la prima versione diffusa per la consultazione pubblica. Può essere rivista, riorganizzata o vedere modificate le proprie date prima della pubblicazione di una versione definitiva. A settembre 2026 nessuna versione definitiva è stata pubblicata.

Va letto insieme a NIST SP 800-131A Rev. 3, anch'esso una bozza pubblica iniziale (21 ottobre 2024, csrc.nist.gov/pubs/sp/800/131/a/r3/ipd). SP 800-131A è la pubblicazione che definisce le regole di transizione degli algoritmi per l'uso federale statunitense, e tali regole si riflettono su ciò che i moduli crittografici validati sono autorizzati a fare: per questo fornitori e auditor seguono da vicino entrambi i documenti. Entrambi sono bozze. Nessuno dei due è una legge, e nessuno dei due è di per sé vincolante per un'azienda privata.

Deprecato e non consentito sono termini tecnici

Nel lessico di transizione del NIST, le due parole non sono sinonimi. Deprecato (deprecated) significa che un algoritmo resta approvato ma il suo uso è sconsigliato e comporta un rischio riconosciuto. Non consentito (disallowed) significa che non è più approvato per l'uso descritto. La bozza propone il primo stato dopo il 2030 e il secondo dopo il 2035, e definisce i termini che utilizza: leggete la bozza stessa prima di citarne una definizione in una policy interna.

Perché la soglia dei 112 bit coincide con RSA-2048

La bozza ragiona in termini di livelli di sicurezza anziché di dimensioni delle chiavi, e RSA-2048 è l'esempio che fornisce per il livello di 112 bit. La conseguenza pratica è che una transizione impostata in questo modo va ben oltre RSA. ECDSA, EdDSA, ECDH, Diffie-Hellman su campi finiti e DSA sono tutti violati dall'algoritmo di Shor su un computer quantistico sufficientemente grande, qualunque sia la dimensione della chiave. DSA non è già più approvato per la generazione di firme secondo FIPS 186-5, che ne consente solo la verifica delle firme esistenti.

Una chiave RSA più lunga non è una migrazione

Passare da RSA-2048 a un modulo più grande aumenta il livello di sicurezza classico, ed è per questo che BSI TR-02102-1 richiede RSA di almeno 3000 bit. Non offre però alcuna protezione contro l'algoritmo di Shor. La risposta quantistica è una diversa famiglia di algoritmi: ML-KEM (meccanismo di incapsulamento delle chiavi, standardizzato in FIPS 203 il 13 agosto 2024) per lo scambio delle chiavi, e ML-DSA o SLH-DSA per le firme. Consultate la pagina ML-KEM per i set di parametri standardizzati e i gruppi TLS che li utilizzano.

Qui l'ordine dei lavori è importante. Harvest now, decrypt later (HNDL, «raccogli ora, decifra dopo») indica un avversario che registra oggi il traffico cifrato per decifrarlo in seguito: le sessioni registrate sono protette soltanto dallo scambio delle chiavi. Per questo lo scambio di chiavi ibrido viene per primo, mentre certificati e firme possono migrare in un secondo momento. Un parco sistemi che firma ancora con certificati RSA-2048 ma negozia un gruppo ibrido ML-KEM si trova in una posizione migliore rispetto alla situazione inversa.

Come si confronta la bozza con BSI, UE e altri

La finestra 2030-2035 non è un'esclusiva del NIST, ma il peso giuridico di ciascun documento varia notevolmente. La tabella seguente mantiene ogni fonte nella propria categoria. L'elenco completo e datato, con le fonti primarie per ogni scadenza, si trova nel nostro articolo di riferimento sulle scadenze della migrazione post-quantistica.

Due punti meritano di essere detti chiaramente. Primo, gli unici obblighi con date certe in questa tabella si applicano alle agenzie federali statunitensi; BSI TR-02102-1 è una linea guida tecnica (il documento stesso), e la roadmap dell'UE è un insieme di orientamenti coordinati rivolti agli Stati membri. L'ANSSI afferma che le sue raccomandazioni PQC non sono ancora obblighi regolamentari al di fuori del proprio ambito regolamentato (qualificazione dei prodotti e alcuni operatori regolamentati), dove l'ibridazione è obbligatoria; intende richiedere la PQC per i prodotti che entrano in qualificazione a partire dal 2027 e ritiene che dopo il 2030 acquistare prodotti privi di PQC non sarà ragionevole, il che costituisce una raccomandazione. Secondo, tutti questi testi convergono sugli stessi due primi passi, l'inventario e lo scambio di chiavi ibrido: per questo l'esito della bozza non cambia ciò che occorre fare oggi.

Cosa fare finché la bozza resta una bozza

Questo articolo ha finalità informative e non costituisce consulenza legale. La sequenza seguente è normale lavoro di ingegneria, ed è la stessa sia che la versione definitiva di NIST IR 8547 mantenga, sposti o attenui le date proposte.

1. Sapere dove si trova RSA-2048. Inventariate chiavi, certificati e configurazioni TLS, con dimensione della chiave, algoritmo di firma, responsabile e scadenza. Il requisito 12.3.3 di PCI DSS v4.0.1 richiede che le cipher suite e i protocolli in uso siano documentati e riesaminati almeno ogni 12 mesi, inclusa una strategia documentata per i cambiamenti previsti nelle vulnerabilità crittografiche; è obbligatorio dal 31 marzo 2025.
2. Scrivere la clausola di agilità, non l'algoritmo. Il RTS DORA, Regolamento delegato (UE) 2024/1774 della Commissione, Art. 6, richiede letteralmente una policy di cifratura e controlli crittografici che includa disposizioni per l'aggiornamento o la sostituzione della tecnologia crittografica in base agli sviluppi della crittoanalisi, e l'Art. 7 richiede la gestione delle chiavi lungo l'intero ciclo di vita oltre a un registro dei certificati per gli asset ICT che supportano funzioni essenziali o importanti. Consultate la pagina DORA per l'ambito esatto. Nostra interpretazione, non un requisito letterale: una policy che indica un evento che attiva il riesame (ad esempio la pubblicazione di un documento di transizione NIST definitivo) è un modo più semplice per soddisfare l'Art. 6 rispetto a una policy che indica RSA-2048 e una data.
3. Attivare lo scambio di chiavi ibrido dove le sessioni vengono registrate. Prima la terminazione TLS e VPN esposta al pubblico, poiché è questo il bersaglio dell'HNDL.
4. Limitare consapevolmente la durata dei certificati. Un certificato RSA-2048 emesso oggi non dovrebbe essere pensato per restare valido oltre la finestra temporale rilevante per il vostro settore.

Prima i controlli in sola lettura. Questi comandi riportano ciò che è effettivamente in produzione, non ciò che afferma la documentazione:

openssl x509 -in server.crt -noout -subject -enddate
openssl x509 -in server.crt -noout -text | grep -E "Public-Key|Signature Algorithm"
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null

I gruppi TLS ML-KEM richiedono OpenSSL 3.5 o successivo, quindi un client più vecchio rifiuterà il nome del gruppo, indipendentemente dal server. Quando passate alle modifiche di configurazione, mantenete un fallback classico (elencate X25519 dopo X25519MLKEM768) e testate in staging prima della produzione.

Prossimo passo: misurare, poi pianificare

Prima di citare la data di una bozza in un documento per il consiglio di amministrazione, verificate i fatti sul vostro perimetro: se i vostri server negoziano già un gruppo ibrido ML-KEM, quali versioni di TLS accettano e quali dimensioni di chiave e algoritmi di firma compaiono nella catena di certificati. Potete analizzare il vostro dominio con PQC Status gratuitamente e usare il risultato come prima riga dell'inventario descritto sopra. Una scansione descrive solo la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità.