ML-KEM vs ML-DSA vs SLH-DSA: crittografia post quantistica

Il 13 agosto 2024 il NIST ha approvato tre standard destinati a cambiare il modo in cui proteggiamo dati e comunicazioni: FIPS 203, FIPS 204 e FIPS 205. Due anni dopo, nell’ottobre 2026, quegli standard sono già nei browser, nelle app di messaggistica e nei primi piani di migrazione dei governi europei. Il problema è che i tre algoritmi che ne derivano, ML-KEM, ML-DSA e SLH-DSA, non sono intercambiabili e non risolvono lo stesso problema. Chi deve scegliere oggi quale adottare, e quando, si trova davanti a decisioni tecniche con conseguenze che dureranno un decennio.

Questo confronto mette uno di fronte all’altro i tre standard di crittografia post-quantistica del NIST: dimensioni delle chiavi, velocità reali misurate su hardware di produzione e consumer, costi di adozione, scadenze normative europee e, soprattutto, quale scegliere in base al proprio caso d’uso. Chi lavora nel settore della crittografia applicata troverà qui i numeri necessari per smettere di rimandare la decisione.

Perché la crittografia post-quantistica non è più teoria

Gli algoritmi a chiave pubblica che usiamo da trent’anni, RSA e la crittografia a curve elittiche, si basano su problemi matematici che un computer classico non può risolvere in tempi utili. Un computer quantistico sufficientemente grande, eseguendo l’algoritmo di Shor, li romperebbe in ore. Nessun computer quantistico di quella scala esiste ancora nel 2026, ma il rischio non riguarda solo il futuro: riguarda anche i dati cifrati oggi.

È la logica dello harvest now, decrypt later: un avversario intercetta e archivia traffico cifrato adesso, per decifrarlo quando avrà la potenza di calcolo necessaria. Per contratti commerciali di breve durata il rischio è trascurabile. Per segreti industriali, cartelle sanitarie, documenti diplomatici o firme digitali con validità legale di decenni, il calcolo cambia radicalmente. È per questo che enti come il BSI tedesco e il NIS Cooperation Group europeo hanno iniziato a fissare scadenze di migrazione già nel 2025, molto prima che un computer quantistico rilevante sia mai stato costruito.

I tre standard NIST affrontano due problemi distinti. ML-KEM serve a stabilire una chiave condivisa tra due parti, lo stesso ruolo che oggi svolgono RSA e Diffie-Hellman su curve elittiche, argomento che abbiamo già trattato parlando di ECDH ed ECDSA in Node.js. ML-DSA e SLH-DSA, invece, servono a firmare digitalmente: garantiscono che un messaggio, un certificato o un aggiornamento software provenga davvero da chi dice di averlo inviato e non sia stato alterato.

Perché il NIST ha scelto tre standard e non uno solo

Una domanda che si sente spesso è perché il NIST non abbia semplicemente indicato “l’algoritmo post-quantistico migliore” e abbia invece standardizzato tre famiglie diverse. La risposta sta nella differenza tra i problemi da risolvere e nella necessità di non dipendere da un’unica ipotesi matematica. ML-KEM e ML-DSA condividono la base sui reticoli modulari: è un’ipotesi di sicurezza relativamente giovane rispetto a RSA, studiata a fondo durante la competizione NIST ma comunque più recente dei problemi su cui si fonda la crittografia classica.

SLH-DSA esiste proprio per questo motivo: offre un’alternativa di firma che non dipende in alcun modo dai reticoli. Se in futuro un ricercatore trovasse un attacco efficace contro i problemi reticolari che sostengono ML-KEM e ML-DSA, le organizzazioni che hanno già distribuito SLH-DSA per i propri sistemi più sensibili avrebbero già un piano B pronto, senza bisogno di una migrazione d’emergenza. È lo stesso principio di ridondanza che guida molte decisioni di architettura dei sistemi distribuiti, applicato alla matematica della sicurezza.

ML-KEM: lo standard per lo scambio di chiavi (FIPS 203)

ML-KEM, acronimo di Module-Lattice-Based Key-Encapsulation Mechanism, deriva direttamente da Kyber, l’algoritmo che aveva vinto la competizione NIST per il key encapsulation. Si basa su reticoli modulari e sul problema Module Learning With Errors (MLWE), ritenuto resistente sia agli attacchi classici che a quelli quantistici noti. Non è un algoritmo di firma: il suo unico compito è permettere a due parti di concordare un segreto condiviso di 32 byte, che verrà poi usato per cifrare la sessione con un algoritmo simmetrico come AES-256.

Il NIST definisce tre parametrizzazioni. ML-KEM-512, pensato per un livello di sicurezza paragonabile ad AES-128, usa una chiave pubblica di 800 byte e un ciphertext di 768 byte. ML-KEM-768, il profilo diventato il default pratico per l’uso aziendale e per TLS ibrido, porta la chiave pubblica a 1.184 byte, la chiave privata a 2.400 byte e il ciphertext a 1.088 byte. ML-KEM-1024, riservato a scenari con requisiti di sicurezza più elevati, arriva a una chiave pubblica di 1.568 byte e un ciphertext della stessa dimensione.

Il vantaggio operativo di ML-KEM è che le sue dimensioni restano gestibili. Rispetto a una chiave ECDH su curva P-256, che occupa appena 32-65 byte, l’overhead è reale ma non proibitivo per la maggior parte dei protocolli di rete moderni. È il motivo per cui ML-KEM è, tra i tre standard, quello già distribuito più ampiamente in produzione.

ML-DSA: le firme digitali su base reticolare (FIPS 204)

ML-DSA, Module-Lattice-Based Digital Signature Algorithm, deriva da Dilithium e condivide con ML-KEM la base matematica sui reticoli. A differenza di ML-KEM, però, il suo scopo è generare e verificare firme digitali: lo stesso ruolo che oggi svolgono RSA-PSS ed ECDSA per certificati TLS, firma del codice e documenti.

Anche qui il NIST definisce tre livelli. ML-DSA-44, al livello di sicurezza NIST 2, usa una chiave pubblica di 1.312 byte e produce firme di 2.420 byte. ML-DSA-65, il profilo di livello NIST 3 considerato il più equilibrato per l’adozione generalista, porta la chiave pubblica a 1.952 byte, la chiave privata a circa 4.032 byte e la firma a 3.309 byte. ML-DSA-87, al livello di sicurezza più alto, arriva a una chiave pubblica di 2.592 byte e firme di 4.627 byte.

Il punto debole di ML-DSA non è la velocità, che su microcontrollori moderni resta entro un ordine di grandezza rispetto a ECDSA, ma la dimensione delle firme. Una firma ECDSA su curva P-256 pesa circa 64-72 byte. Una firma ML-DSA-65 ne pesa 3.309, quasi cinquanta volte tanto. Per protocolli che scambiano migliaia di firme al secondo, come alcune blockchain o sistemi di telemetria IoT ad alta frequenza, questo moltiplicatore pesa sulla larghezza di banda in modo diretto.

SLH-DSA: l’alternativa basata su funzioni hash (FIPS 205)

SLH-DSA, Stateless Hash-Based Digital Signature Algorithm, deriva da SPHINCS+ e rompe con la logica reticolare degli altri due standard. La sua sicurezza si fonda esclusivamente sulle proprietà delle funzioni hash, la stessa famiglia di primitive che abbiamo analizzato nella nostra guida a SHA-256. Non esiste un problema matematico “nuovo” da attaccare: se le funzioni hash sottostanti restano sicure, lo è anche SLH-DSA. È per questo che il NIST lo descrive come la scelta di backup, pensata per il giorno in cui qualcuno trovasse una debolezza nei reticoli modulari su cui si basano ML-KEM e ML-DSA.

Il compromesso è nelle dimensioni, ma rovesciato rispetto a ML-DSA. Le chiavi pubbliche di SLH-DSA restano piccolissime, tra 32 e 64 byte in base al profilo, ma le firme diventano enormi: da circa 7,8 KB nei profili più compatti fino quasi a 50 KB nei profili con sicurezza a 256 bit. Un profilo “fast” a 128 bit produce firme da circa 17.088 byte. Il corrispondente profilo a 256 bit arriva a circa 49.856 byte. Significa che una singola firma SLH-DSA al livello di sicurezza più alto può pesare fino a 15 volte più di una firma ML-DSA-65.

Anche la velocità di firma risente di questa architettura: SLH-DSA è sensibilmente più lento in fase di generazione della firma rispetto a ML-DSA, con i profili più compatti che scendono a prestazioni a singola o doppia cifra al secondo su hardware vincolato. La verifica, al contrario, resta relativamente rapida su tutti i profili.

Gli algoritmi rimasti fuori: Falcon, BIKE e HQC

ML-KEM, ML-DSA e SLH-DSA non sono stati gli unici candidati esaminati dal NIST, e vale la pena sapere cosa è rimasto indietro per capire meglio dove si colloca lo stato dell’arte a ottobre 2026. Falcon, un altro algoritmo di firma su base reticolare che offre firme più compatte di ML-DSA, è stato selezionato dal NIST ma il suo standard risultava ancora in fase di bozza nel 2026, non ancora pubblicato come FIPS ufficiale. Chi ha bisogno oggi di firme reticolari compatte e standardizzate deve quindi orientarsi su ML-DSA, non su Falcon.

Sul fronte dello scambio di chiavi, il NIST ha avviato anche un secondo round di standardizzazione per algoritmi di backup basati su codici correttori d’errore, tra cui BIKE e HQC, pensati come alternativa a ML-KEM nel caso in cui emergesse una debolezza nei reticoli modulari. Questi algoritmi restano, a ottobre 2026, in una fase di valutazione meno avanzata rispetto ai tre standard principali e non hanno ancora lo stesso livello di adozione in produzione. Per chi pianifica un’architettura oggi, la scelta pratica resta quindi tra ML-KEM, ML-DSA e SLH-DSA, con gli altri candidati da tenere d’occhio per gli anni successivi.

Tabella comparativa: le specifiche tecniche fianco a fianco

Caratteristica	ML-KEM-768	ML-DSA-65	SLH-DSA (SHA2-128f)
Standard FIPS	FIPS 203	FIPS 204	FIPS 205
Algoritmo di origine	Kyber	Dilithium	SPHINCS+
Funzione	Scambio di chiavi (KEM)	Firma digitale	Firma digitale
Base matematica	Reticoli modulari (MLWE)	Reticoli modulari (MLWE/MSIS)	Funzioni hash
Livello di sicurezza NIST	3	3	1 (variante fast)
Dimensione chiave pubblica	1.184 byte	1.952 byte	32 byte
Dimensione chiave privata	2.400 byte	~4.032 byte	64 byte
Output principale	Ciphertext 1.088 byte	Firma 3.309 byte	Firma ~17.088 byte
Velocità operazione principale	Alta	Alta	Bassa (profili fast)
Velocità di verifica	Alta	Alta	Media-alta
Overhead vs algoritmo classico equivalente	~17x su ECDH	~46x su ECDSA	~237x su ECDSA
Adozione in produzione a ottobre 2026	Ampia (browser, CDN, messaggistica)	In crescita (PKI, firmware)	Limitata (casi di nicchia ad alta garanzia)
Caso d’uso consigliato	Handshake TLS, VPN, messaggistica	Certificati, firma codice generalista	Firmware critico, archiviazione a lunghissimo termine

Il quadro che emerge dalla tabella è chiaro: ML-KEM e ML-DSA condividono la stessa base matematica e restano relativamente compatti, mentre SLH-DSA sacrifica le dimensioni della firma in cambio di una base di sicurezza matematicamente indipendente. Non è un dettaglio da ingegneri: è la ragione per cui molte organizzazioni stanno pianificando di usare ML-DSA come firma primaria e SLH-DSA solo come riserva per i sistemi più critici.

Benchmark reali: cosa dicono le misurazioni su hardware

I numeri di laboratorio contano poco se non si traducono in prestazioni su hardware reale. Tre fonti indipendenti pubblicate nel 2026 offrono un quadro coerente, anche se con alcune differenze nei dettagli che vale la pena segnalare prima di trarre conclusioni ferme sui singoli numeri.

Uno studio pubblicato su PLOS One ha valutato la fattibilità hardware di ML-KEM, ML-DSA e SLH-DSA su un microcontrollore ESP32-C6, la famiglia di chip usata in milioni di dispositivi IoT. La conclusione centrale è che, man mano che si sale di livello di sicurezza da ML-KEM-512 a ML-KEM-768 e ML-KEM-1024, le dimensioni di chiavi e ciphertext crescono in modo proporzionale ai requisiti computazionali e di memoria più elevati, un andamento previsto ma che pesa sulla scelta dei profili per dispositivi con RAM limitata.

Una seconda fonte, ripresa da una pubblicazione tecnica del 2026 su Frontiers sulla sicurezza post-quantistica in ambito sanitario, riporta benchmark su Cortex-M0+ e Cortex-M4, due famiglie di microcontrollori molto diffuse nei dispositivi medici connessi. Su Cortex-M0+, la firma ML-DSA mostra latenze al 99° percentile di circa 0,5 secondi per ML-DSA-44 e oltre 1 secondo per ML-DSA-87. Su Cortex-M4, invece, ML-KEM risulta più rapido di ECDH nello stesso scenario, mentre ML-DSA resta entro un ordine di grandezza rispetto a ECDSA: il problema operativo principale, anche qui, è la dimensione di chiavi e firme più che il tempo di calcolo puro.

Una terza fonte tecnica, citata dal blog di Hive Security, descrive SLH-DSA come sensibilmente più lento in fase di firma rispetto a ML-DSA: i profili con firme più compatte possono scendere a prestazioni nell’ordine delle due cifre al secondo o meno, a seconda del profilo scelto e del livello di sicurezza richiesto. La verifica, al contrario, resta relativamente rapida su tutti e tre gli standard, un dettaglio importante per i sistemi che verificano molte più firme di quante ne generino, come i client TLS o i lettori di firmware firmato.

Il filo comune tra le tre fonti è questo: su hardware vincolato, ML-KEM è quasi sempre la scelta più economica in termini di CPU e banda. ML-DSA resta gestibile. SLH-DSA richiede una valutazione caso per caso, perché il costo in tempo di firma e banda può diventare rilevante su dispositivi con risorse limitate o connessioni a basso throughput.

Per orientarsi rapidamente tra le fonti citate, questa tabella riassume dove ciascun benchmark ha misurato i tre standard e cosa ha trovato.

Fonte	Hardware testato	Algoritmi coperti	Risultato principale
PLOS One (2026)	ESP32-C6 (IoT)	ML-KEM, ML-DSA, SLH-DSA	Crescita proporzionale di dimensioni e requisiti computazionali dal livello 512 al 1024
Frontiers Health Services (2026)	Cortex-M0+, Cortex-M4	ML-KEM, ML-DSA vs ECDH/ECDSA	ML-KEM più rapido di ECDH su Cortex-M4; ML-DSA entro un ordine di grandezza da ECDSA
Hive Security (2026)	Non specificato, analisi comparativa	SLH-DSA vs ML-DSA	SLH-DSA molto più lento in firma, verifica comparabile

Costi e modelli di adozione: quanto costa davvero migrare

A differenza di un prodotto commerciale, ML-KEM, ML-DSA e SLH-DSA sono standard pubblici: non esiste un prezzo di licenza per usarli. Il costo reale della migrazione sta altrove, nelle librerie, nell’infrastruttura e nel lavoro di integrazione. Questa tabella riassume i principali modelli di costo disponibili a ottobre 2026.

Soluzione	Tipo	Modello di costo	Note
OpenSSL 3.5+ con ML-KEM	Libreria open source	Gratuito	Supporto nativo a ML-KEM, approfondito nella nostra guida a OpenSSL 3.5 e ML-KEM
liboqs (Open Quantum Safe)	Libreria open source	Gratuito	Implementazione di riferimento per tutti e tre gli standard NIST
BoringSSL	Libreria open source	Gratuito	Mantenuta da Google, usata in Chrome e in parte dell’infrastruttura Android
Cloudflare TLS ibrido	Servizio gestito	Incluso nel piano esistente	ML-KEM ibrido abilitato di default dalla fine del 2024
Chrome 131+	Browser	Gratuito	Meccanismo ibrido basato su ML-KEM abilitato di default
HSM e KMS enterprise (es. Thales, Entrust)	Hardware/servizio enterprise	Licenza o quotazione su richiesta	Supporto PQC in roll-out progressivo sulle linee di prodotto più recenti
Audit e consulenza di migrazione	Servizio professionale	Preventivo caso per caso	Costo variabile in base a inventario crittografico e superficie applicativa

La voce di costo più sottovalutata non è la libreria crittografica, che nella maggior parte dei casi è gratuita, ma l’inventario: capire dove, nell’intera infrastruttura, viene usata crittografia a chiave pubblica classica. Senza quell’inventario, qualsiasi stima di budget per la migrazione resta un numero buttato lì a caso.

Chi usa già cosa: cinque esempi reali di adozione

Cloudflare ha abilitato ML-KEM in modalità ibrida come impostazione predefinita per il traffico TLS alla fine del 2024, rendendola probabilmente la più grande distribuzione di crittografia post-quantistica in produzione al mondo per volume di connessioni.
Chrome 131 ha abilitato di default un meccanismo di scambio chiavi ibrido basato su ML-KEM, estendendo la protezione post-quantistica a miliardi di sessioni di navigazione senza richiedere alcuna azione da parte dell’utente.
Signal ha introdotto PQXDH per proteggere lo stabilimento delle sessioni con ML-KEM e, nel 2025, ha annunciato sviluppi ulteriori legati a SPQR e al Triple Ratchet per estendere la protezione post-quantistica anche alle conversazioni in corso, non solo all’avvio della sessione.
Apple figura tra i fornitori che hanno distribuito scambi di chiavi post-quantistici in iMessage e FaceTime su iOS 18 e macOS Sequoia, portando ML-KEM su centinaia di milioni di dispositivi consumer.
Google e AWS compaiono nelle panoramiche 2026 sull’adozione enterprise della crittografia post-quantistica, anche se con un dettaglio tecnico e tempistiche di roll-out meno granulari rispetto ai casi di Cloudflare, Chrome, Apple e Signal.

Il pattern che emerge da questi cinque casi è coerente: chi ha mosso per primo lo ha fatto quasi sempre con ML-KEM in modalità ibrida, cioè affiancando l’algoritmo post-quantistico a un algoritmo classico come X25519, non sostituendolo. È una scelta prudente: se nei prossimi anni emergesse una debolezza in ML-KEM, la sicurezza del canale resterebbe comunque garantita dalla componente classica.

Le scadenze europee: BSI, NIS Cooperation Group ed ENISA

Per chi opera in Europa, la domanda non è solo tecnica ma normativa: quando bisogna aver completato la migrazione? Le fonti disponibili nel 2026 offrono un quadro a più livelli, con alcune differenze tra le linee guida nazionali e quelle europee.

Ente	Ambito	Scadenza chiave
NIS Cooperation Group (UE)	Roadmap coordinata, pubblicata a giugno 2025	Inventari e avvio transizione entro fine 2026; casi ad alto rischio entro fine 2030; estensione quanto più possibile entro il 2035
BSI (Germania)	Guida tecnica 2026-01, datata 23 gennaio 2026	Scambio di chiavi classico autonomo ammesso solo fino a fine 2031 (fine 2030 per protezione molto elevata); firme classiche fino a fine 2035
NCSC (Regno Unito)	Roadmap 2025, riferimento comparativo extra-UE	Obiettivi e inventario entro il 2028; priorità alte entro il 2031; completamento entro il 2035
ANSSI (Francia) ed ENISA	Linee guida citate nei confronti europei 2026	Incluse nel confronto delle linee guida nazionali, senza scadenze numeriche separate dello stesso livello di dettaglio della roadmap UE e del documento BSI

Il confronto tra le linee guida nazionali ed europee, ricostruito in dettaglio da Cryptagion, mostra un punto di convergenza: tutti gli enti coinvolti indicano la fine del 2026 come la finestra in cui le organizzazioni dovrebbero aver completato almeno l’inventario della propria crittografia, il primo passo di qualsiasi piano di migrazione serio. Le scadenze per la migrazione effettiva, invece, si allungano fino al 2030-2035 in base al livello di rischio dei dati trattati.

Per le aziende italiane ed europee, la fine del 2026 è quindi più vicina di quanto suggerisca il calendario delle scadenze finali. Chi non ha ancora un inventario crittografico completo sta già perdendo tempo rispetto alla finestra raccomandata dal NIS Cooperation Group.

Guida alla migrazione: dalla crittografia classica al post-quantum

Migrare non significa spegnere RSA ed ECC un venerdì e accendere ML-KEM il lunedì successivo. Significa costruire crypto-agilità: la capacità di cambiare algoritmo senza riscrivere l’intera applicazione. È un lavoro che coinvolge team diversi, dalla sicurezza allo sviluppo fino alle operazioni di rete, e che raramente si completa in un singolo trimestre, soprattutto in organizzazioni con sistemi legacy stratificati su più generazioni di infrastruttura. Ecco i passaggi che la maggior parte delle guide tecniche 2026 raccomanda, in ordine.

Inventario crittografico. Elencare ogni punto dell’infrastruttura in cui viene usata crittografia a chiave pubblica: TLS, VPN, firma del codice, PKI interna, firmware, backup a lungo termine.
Classificazione del rischio per dato. Separare i dati che richiedono riservatezza solo per pochi mesi da quelli che devono restare protetti per decenni, come cartelle sanitarie o segreti industriali.
Aggiornamento delle librerie di base. Passare a versioni di OpenSSL, liboqs o BoringSSL che supportano nativamente ML-KEM, ML-DSA e SLH-DSA, come descritto nella nostra guida pratica a OpenSSL 3.5.
Attivazione della modalità ibrida. Affiancare l’algoritmo post-quantistico a quello classico (es. ML-KEM + X25519) prima di eliminare completamente il supporto classico, replicando l’approccio già scelto da Cloudflare e Chrome.
Test di interoperabilità. Verificare che client, server, proxy e bilanciatori di carico gestiscano correttamente i pacchetti più grandi generati dai nuovi algoritmi, specialmente in reti con MTU ridotta.
Aggiornamento della PKI interna. Valutare se emettere certificati con firme ML-DSA o se mantenere certificati ibridi durante la fase di transizione.
Pianificazione per i sistemi vincolati. Per IoT, firmware e dispositivi embedded, valutare attentamente l’overhead di banda e memoria prima di scegliere tra ML-DSA e SLH-DSA.
Monitoraggio delle scadenze normative. Allineare il piano interno alle date fissate da BSI, NIS Cooperation Group e, se applicabile, dal proprio regolatore di settore.

Un dettaglio spesso trascurato: la migrazione delle chiavi di scambio e delle firme digitali non risolve, e non sostituisce, la scelta degli algoritmi di hashing delle password, un problema diverso che abbiamo affrontato nel confronto tra Bcrypt, Argon2 e Scrypt. Sono due superfici di rischio distinte, e vanno pianificate separatamente.

Un esempio pratico: testare ML-KEM con OpenSSL 3.5

Per chi vuole verificare concretamente il comportamento di ML-KEM prima di pianificare un roll-out più ampio, OpenSSL 3.5 permette di generare una coppia di chiavi e testare l’handshake ibrido con pochi comandi.

# Genera una coppia di chiavi ML-KEM-768
openssl genpkey -algorithm ML-KEM-768 -out mlkem768_private.pem

# Verifica il gruppo di scambio chiavi ibrido supportato dal server
openssl s_client -connect example.com:443 -groups X25519MLKEM768

# Elenca i gruppi post-quantistici disponibili nella build locale
openssl list -kem-algorithms

Il gruppo X25519MLKEM768 è esattamente l’approccio ibrido adottato da Chrome e Cloudflare: combina la sicurezza post-quantistica di ML-KEM con la robustezza collaudata di X25519 su curva elittica. Per un approfondimento sulla configurazione completa di TLS con questo stack, la nostra guida dedicata a OpenSSL 3.5 e ML-KEM copre anche la generazione dei certificati e la configurazione del server.

Prima di distribuire questa configurazione in produzione, vale la pena testarla contro i propri bilanciatori di carico e contro eventuali proxy intermedi: i pacchetti ibridi sono più grandi di un semplice handshake X25519, e alcune implementazioni più vecchie di TLS possono troncare o rifiutare pacchetti ClientHello sopra una certa soglia. È un problema di compatibilità, non di sicurezza, ma è esattamente il tipo di dettaglio che un test di interoperabilità ben fatto individua prima del rollout, non dopo.

Pro e contro: i tre standard a confronto diretto

ML-KEM

Pro: dimensioni di chiavi e ciphertext contenute, già integrato in browser e CDN, prestazioni elevate anche su hardware vincolato, standardizzazione completa e stabile da agosto 2024.
Contro: risolve solo lo scambio di chiavi, non le firme, e va sempre combinato con un algoritmo di firma separato (ML-DSA o SLH-DSA) per completare lo stack crittografico.

ML-DSA

Pro: buon equilibrio tra dimensione delle firme e velocità, candidato generalista per PKI e firma del codice, prestazioni su microcontrollori entro un ordine di grandezza rispetto a ECDSA.
Contro: firme fino a quasi 50 volte più pesanti di ECDSA, condivide la base matematica reticolare con ML-KEM (meno diversificazione se emergesse una debolezza comune ai reticoli modulari).

SLH-DSA

Pro: base di sicurezza indipendente dai reticoli (solo funzioni hash), chiavi pubbliche piccolissime, scelta prudente per sistemi che devono restare sicuri anche in scenari estremi.
Contro: firme enormi, fino a 15 volte più pesanti di ML-DSA-65 nei profili a sicurezza più alta, velocità di firma bassa nei profili compatti, poco adatto a scenari con molte operazioni di firma al secondo.

Quale scegliere: cinque casi d’uso e la raccomandazione

Non esiste un vincitore unico tra i tre standard, perché risolvono problemi diversi o li risolvono con compromessi diversi. Ecco come orientarsi in base allo scenario concreto.

Handshake TLS e VPN: ML-KEM in modalità ibrida con un algoritmo classico (es. X25519MLKEM768), lo stesso schema già in produzione su Cloudflare e Chrome.
Messaggistica cifrata end-to-end: ML-KEM per lo stabilimento della sessione, seguendo l’approccio di Signal con PQXDH e degli sviluppi successivi con SPQR.
Certificati TLS e firma del codice generalista: ML-DSA-65, il profilo con il miglior equilibrio tra dimensione della firma e velocità per l’uso quotidiano in PKI aziendale.
Firmware per dispositivi IoT con connessioni a basso throughput: valutare ML-DSA come prima opzione, riservando SLH-DSA solo se la diversificazione dall’algebra reticolare è un requisito esplicito di sicurezza.
Archiviazione di documenti con validità legale pluridecennale o firma di root CA: SLH-DSA, nonostante le firme più pesanti, per la garanzia di una base di sicurezza matematicamente indipendente da ML-KEM e ML-DSA.

Un principio guida pratico, già adottato dalla maggior parte delle aziende che hanno iniziato la migrazione: usare ML-KEM ovunque per lo scambio di chiavi, usare ML-DSA come firma primaria per la quasi totalità degli scenari, e riservare SLH-DSA a un sottoinsieme ristretto di casi dove la diversificazione algebrica vale il costo in banda e tempo di firma.

Crypto-agilità: la competenza che conta più dell’algoritmo

C’è un errore ricorrente in chi affronta per la prima volta la migrazione post-quantistica: concentrarsi sulla scelta “giusta” tra ML-KEM, ML-DSA e SLH-DSA come se fosse una decisione fissata una volta per sempre e irreversibile. Non lo è, e non dovrebbe esserlo. La vera competenza da costruire non è scegliere l’algoritmo perfetto al primo tentativo, ma progettare sistemi capaci di cambiare algoritmo rapidamente quando le circostanze lo richiedono.

In pratica significa separare la logica di negoziazione crittografica dal resto dell’applicazione, evitare di scrivere firme o ciphertext con dimensioni hard-coded nei protocolli interni, e mantenere la possibilità di aggiungere o rimuovere un algoritmo dalla lista supportata tramite configurazione, non tramite un rilascio di codice. È lo stesso principio che ha permesso a Cloudflare e Chrome di passare dalla modalità classica a quella ibrida senza interruzioni visibili per gli utenti finali.

Le organizzazioni che oggi faticano più con la transizione non sono quelle che hanno scelto il parametro sbagliato tra ML-DSA-44 e ML-DSA-65. Sono quelle che, anni fa, hanno costruito protocolli interni assumendo che le firme ECDSA sarebbero sempre rimaste a 64-72 byte. Quell’assunzione, oggi, è il vero costo nascosto della migrazione, molto più della scelta tra i tre standard NIST.

Verdetto: i numeri che contano davvero

Riassumendo i dati raccolti in questo confronto: ML-KEM-768 pesa 1.184 byte di chiave pubblica contro gli 800-1.568 byte delle altre varianti dello stesso standard, con un overhead di circa 17 volte rispetto a ECDH ma prestazioni che bastano per il traffico TLS di massa, come dimostra l’adozione di Cloudflare e Chrome. ML-DSA-65 produce firme di 3.309 byte, circa 46 volte più pesanti di ECDSA, ma resta la scelta più equilibrata per PKI e firma del codice. SLH-DSA, con firme che arrivano a 49.856 byte nei profili a sicurezza più alta, fino a 15 volte più pesanti di ML-DSA, resta l’opzione di riserva per chi vuole una base di sicurezza del tutto indipendente dai reticoli modulari.

La scadenza da tenere a mente è una sola, almeno per il breve termine: la fine del 2026, il momento in cui il NIS Cooperation Group europeo raccomanda di aver completato l’inventario crittografico e avviato la transizione. Non è una scadenza per aver finito la migrazione, ma per aver smesso di rimandarla. Chi si occupa di sicurezza delle chiavi SSH e dell’hardening dei server farebbe bene a includere questo inventario nella prossima revisione di sicurezza, non in quella dell’anno prossimo.

Per chi deve riferire questa decisione a un team di direzione, il messaggio sintetico è questo: ML-KEM è pronto, testato in produzione su scala planetaria da Cloudflare e Chrome, e va adottato subito in modalità ibrida ovunque ci sia un handshake TLS o una VPN da proteggere. ML-DSA è la scelta di firma predefinita per certificati e firma del codice, con un costo in banda accettabile per la stragrande maggioranza degli scenari aziendali. SLH-DSA resta una riserva strategica, da riservare ai sistemi dove l’indipendenza dai reticoli modulari vale il prezzo in byte e in tempo di firma. Nessuno dei tre standard è opzionale nel medio periodo: la sola domanda aperta è quanto velocemente la propria organizzazione riuscirà a passare dalla teoria alla produzione.

Domande frequenti

ML-KEM, ML-DSA e SLH-DSA sono compatibili tra loro?
Sì, ma svolgono ruoli diversi e complementari: ML-KEM gestisce lo scambio di chiavi, ML-DSA e SLH-DSA gestiscono le firme digitali. Uno stack TLS completo può usare ML-KEM per l’handshake e ML-DSA per il certificato del server nella stessa connessione.

Devo sostituire subito RSA ed ECC con questi nuovi standard?
La pratica raccomandata nel 2026 è la modalità ibrida: affiancare l’algoritmo post-quantistico a quello classico, non sostituirlo immediatamente. È l’approccio già scelto da Cloudflare e Chrome con il gruppo X25519MLKEM768.

Perché le firme SLH-DSA sono così più grandi di quelle ML-DSA?
Perché si basano su funzioni hash invece che su reticoli modulari. La base hash è considerata più conservativa dal punto di vista della sicurezza, ma richiede strutture di firma più voluminose per garantire lo stesso livello di protezione.

Quale libreria open source supporta tutti e tre gli standard?
liboqs (Open Quantum Safe) è l’implementazione di riferimento per ML-KEM, ML-DSA e SLH-DSA. OpenSSL 3.5 integra nativamente ML-KEM, mentre BoringSSL di Google supporta ML-KEM nell’infrastruttura usata da Chrome.

Qual è la scadenza europea più urgente da conoscere?
La fine del 2026, raccomandata dal NIS Cooperation Group per completare l’inventario crittografico e avviare la transizione. Le scadenze per la migrazione effettiva dei casi a più alto rischio si estendono fino al 2030-2035, in base alle linee guida di BSI e NCSC.

I dispositivi IoT con poca memoria possono usare questi algoritmi?
ML-KEM è generalmente gestibile anche su microcontrollori con risorse limitate, come dimostrano i test su ESP32-C6 e Cortex-M0+/M4. SLH-DSA, per via delle firme molto più grandi, richiede una valutazione più attenta su dispositivi con memoria e banda ridotte.

Signal e Apple usano già questi standard?
Sì. Signal usa ML-KEM tramite PQXDH per lo stabilimento delle sessioni, con sviluppi ulteriori annunciati nel 2025 legati a SPQR. Apple ha distribuito scambi di chiavi post-quantistici basati su ML-KEM in iMessage e FaceTime a partire da iOS 18 e macOS Sequoia.

Cosa cambia per chi gestisce certificati TLS aziendali?
Nel breve termine, poco: la maggior parte delle CA pubbliche sta ancora valutando i tempi di emissione di certificati con firme ML-DSA. Nel medio termine, chi gestisce una PKI interna dovrebbe iniziare a testare certificati ibridi e pianificare la migrazione seguendo le scadenze di inventario fissate per la fine del 2026.

Falcon è un’alternativa valida a ML-DSA già oggi?
No, non ancora in produzione. Falcon offre firme più compatte di ML-DSA ma il suo standard restava in fase di bozza nel 2026, senza una pubblicazione FIPS ufficiale. Chi ha bisogno di firme reticolari standardizzate oggi deve usare ML-DSA.

Conviene aspettare ancora prima di iniziare la migrazione?
No. Le scadenze fissate da NIS Cooperation Group e BSI riguardano l’inventario e l’avvio della transizione entro la fine del 2026, non il completamento. Chi aspetta rischia di dover comprimere in pochi mesi un lavoro che richiede, nella maggior parte dei casi, anni di pianificazione graduale.

Una piccola o media impresa deve affrontare lo stesso costo di migrazione di una grande azienda?
No, non nello stesso modo. Le librerie open source come OpenSSL, liboqs e BoringSSL sono gratuite indipendentemente dalle dimensioni dell’organizzazione, quindi il costo tecnico di base è identico. La differenza sta nella complessità dell’inventario crittografico: una PMI con poche applicazioni web può completare l’inventario e il primo test ibrido in settimane, mentre un’azienda con decine di sistemi legacy e una PKI interna complessa ha bisogno di mesi e, spesso, di una consulenza dedicata per mappare tutte le dipendenze crittografiche prima di muovere il primo passo concreto.