ML-KEM vs Kyber: cosa è cambiato tra la bozza e FIPS 203

CRYSTALS-Kyber e ML-KEM non sono due algoritmi distinti. ML-KEM è la forma standardizzata di CRYSTALS-Kyber, pubblicata dal NIST come FIPS 203 il 13 agosto 2024. Il cambiamento non è solo di facciata: FIPS 203 è una specifica con nomi propri per i set di parametri, formati di chiave propri e regole di validazione proprie, e un'implementazione della precedente proposta presentata alla competizione non interopera con un'implementazione ML-KEM. In TLS, è per questo che il gruppo pre-standard X25519Kyber768Draft00 (codepoint 0x6399) è obsoleto e deve essere sostituito dai gruppi ML-KEM.

Un solo design, due nomi, una sola specifica approvata

Un KEM (key encapsulation mechanism, meccanismo di incapsulamento della chiave) è il componente di un handshake che consente a due parti di concordare un segreto condiviso. CRYSTALS-Kyber era il nome del KEM basato su reticoli presentato al processo di standardizzazione post-quantistica del NIST. Quando il NIST ha emanato lo standard definitivo, l'algoritmo è stato rinominato ML-KEM, abbreviazione di Module-Lattice-Based Key-Encapsulation Mechanism, e specificato in FIPS 203. È stato pubblicato lo stesso giorno insieme a FIPS 204 (ML-DSA, firme) e FIPS 205 (SLH-DSA, firme stateless basate su hash).

Nel linguaggio comune, Kyber e ML-KEM indicano la stessa famiglia di design. Nel codice, in un elenco di gruppi o in un documento di conformità, non sono intercambiabili. Solo ML-KEM come specificato in FIPS 203 è uno standard approvato. Tutto ciò che porta ancora l'etichetta Kyber, Kyber768 o Draft00 è anteriore allo standard. La nostra pagina di riferimento su ML-KEM segue lo standard e il suo stato, e la pagina sulla bozza Kyber segue i gruppi pre-standard che ora dovrebbero essere rimossi dalle configurazioni.

Cosa ha cambiato il passaggio dalla bozza allo standard definitivo

FIPS 203 è stato diffuso come bozza pubblica iniziale per commenti prima che il NIST emanasse il testo definitivo. Tre categorie di modifiche sono rilevanti per un ingegnere o un architetto.

Nomi e set di parametri

Kyber512, Kyber768 e Kyber1024 sono diventati ML-KEM-512, ML-KEM-768 e ML-KEM-1024. FIPS 203 specifica esattamente questi tre set di parametri. Un'opzione di build, una costante o un vettore di test che porta ancora un nome Kyber indica che il codice non è stato aggiornato, non semplicemente che qualcuno ha conservato una vecchia etichetta.

Dettagli della specifica che compromettono l'interoperabilità

Lo standard definitivo differisce dalla precedente proposta presentata alla competizione in alcuni dettagli della specifica, tra cui la generazione delle chiavi, la codifica delle chiavi e la derivazione del segreto condiviso. Questi dettagli sono normativi in FIPS 203 e andrebbero letti lì, anziché in sintesi di seconda mano. La conseguenza pratica è semplice e assoluta: un peer che esegue Kyber pre-standard e un peer che esegue ML-KEM non deriveranno lo stesso segreto condiviso. Non esiste negoziazione tra i due, né percorso di downgrade, né compatibilità parziale. L'handshake fallisce, oppure il gruppo semplicemente non viene mai selezionato.

Regole che un'implementazione deve rispettare

FIPS 203 specifica inoltre i controlli che un'implementazione esegue sul materiale di chiave ricevuto prima di utilizzarlo, e definisce il comportamento della decapsulazione quando l'input non è valido (implicit rejection, che restituisce un segreto condiviso pseudocasuale invece di un errore). La maggior parte di questo onere ricade sugli autori delle librerie. Per chi utilizza una libreria, la lezione è preferire un'implementazione mantenuta che dichiari la conformità a FIPS 203 rispetto a una copia del codice di riferimento risalente al periodo della competizione, e verificare le note di rilascio anziché il nome dell'algoritmo.

I tre set di parametri: 512, 768 e 1024

FIPS 203 definisce i tre set di parametri in relazione alle categorie di sicurezza del NIST. Il numero non è una lunghezza di chiave in bit: è un'etichetta del set di parametri.

Per TLS e SSH di uso generale, ML-KEM-768 all'interno di una costruzione ibrida è il punto su cui l'ecosistema è convergente. Se gestite sistemi che rientrano nell'ambito di NSA CNSA 2.0, la suite indica ML-KEM-1024 insieme a ML-DSA-87, LMS o XMSS, AES-256 e SHA-384 o SHA-512, con un uso esclusivo atteso 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. Altre autorità formulano le proprie posizioni come raccomandazioni: la BSI TR-02102-1 raccomanda lo scambio di chiavi post-quantistico ibrido, e l'ANSSI rende obbligatoria l'ibridazione all'interno del proprio ambito regolamentato, precisando che le sue raccomandazioni post-quantistiche non costituiscono ancora obblighi normativi altrove. Questo articolo ha carattere informativo e non costituisce consulenza legale.

Gruppi TLS: cosa è attuale, cosa è obsoleto

Il named group è la parte visibile di tutto questo. Solo i codepoint riportati di seguito esistono nel registro IANA per ML-KEM, e solo uno di essi è la voce pre-standard obsoleta.

I gruppi ibridi combinano uno scambio di chiavi classico con ML-KEM: in questo modo la sessione resta robusta almeno quanto la parte classica se venisse individuata una debolezza nella costruzione a reticoli, e ottiene una protezione post-quantistica contro il traffico registrato. Questa combinazione è descritta per TLS 1.3 in RFC 10024 (agosto 2026). Il traffico registrato è protetto solo dallo scambio di chiavi, ed è per questo che lo scambio di chiavi migra per primo e i certificati possono seguire in un secondo momento. La pagina su X25519MLKEM768 fornisce il dettaglio del gruppo che la maggior parte dei server dovrebbe abilitare per primo.

Cosa verificare in librerie, server e SSH

Eseguite prima controlli in sola lettura, su un host di staging, prima di modificare una configurazione di produzione.

OpenSSL

Per i gruppi TLS ML-KEM è necessario OpenSSL 3.5 o successivo. Un ramo più vecchio potrebbe ancora annunciare un gruppo della bozza Kyber tramite un provider o una patch della distribuzione: è proprio questo il caso da individuare e rimuovere.

openssl version
openssl list -tls-groups | grep -i mlkem
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Nell'output di s_client, leggete il gruppo negoziato. Se la connessione fallisce con un errore di handshake mentre un gruppo classico funziona, il server non supporta ancora ML-KEM.

Configurazione del server

Mantenete sempre un fallback classico dopo il gruppo ibrido, in modo che i client meno recenti possano comunque connettersi. Su nginx compilato con OpenSSL 3.5 o successivo:

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

La sintassi e i valori supportati variano tra server e tra build delle distribuzioni, quindi verificate sulla vostra versione. La nostra guida all'abilitazione di ML-KEM su nginx, Apache, HAProxy e Caddy illustra la direttiva per ciascuno di essi.

SSH

OpenSSH 9.9 (19 settembre 2024) ha aggiunto mlkem768x25519-sha256, disponibile di default. OpenSSH 10.0 (9 aprile 2025) lo ha reso lo scambio di chiavi predefinito, e OpenSSH 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia uno scambio di chiavi non post-quantistico, tramite l'opzione WarnWeakCrypto abilitata di default. Le versioni precedenti, a partire da OpenSSH 9.0, usano di default l'ibrido sntrup761x25519-sha512@openssh.com, che è post-quantistico ma non è ML-KEM.

ssh -V
ssh -Q kex | grep mlkem

Codice applicativo e dipendenze

• Cercate nei vostri repository e nel configuration management le stringhe Kyber, kyber768, Draft00 e 0x6399. Ogni occorrenza è codice morto oppure una configurazione errata attiva.
• Verificate gli elenchi di gruppi fissati in load balancer, CDN, API gateway, reverse proxy e terminatori TLS. Un elenco fissato è il motivo più comune per cui una libreria moderna negozia ancora un gruppo classico.
• Verificate nelle note di rilascio della vostra libreria crittografica, non nel nome dell'algoritmo, la dichiarazione che l'implementazione segue FIPS 203. Se la validazione FIPS è rilevante per voi, verificate lo stato di validazione del modulo e della versione specifici che distribuite.
• Registrate nel vostro inventario il set di parametri, non solo l'algoritmo: ML-KEM-768 e ML-KEM-1024 sono risposte diverse per un auditor che chiede quale abbiate distribuito.

Verificate cosa negoziano effettivamente i vostri server

Il modo più rapido per sapere se un dominio utilizza lo standard o è ancora su un gruppo della bozza è osservare ciò che offre in rete. Potete analizzare gratuitamente il vostro dominio con PQC Status: lo scanner riporta i gruppi ML-KEM ibridi accettati da un server, le versioni TLS e le cipher suite, e la catena di certificati. Una scansione descrive solo la configurazione TLS visibile dall'esterno. Non è una certificazione né un'attestazione di conformità. Il passo concreto successivo su questo tema: confermate che ogni endpoint pubblico offra X25519MLKEM768 con un fallback classico, quindi rimuovete ogni riferimento residuo al gruppo Kyber pre-standard dalla vostra configurazione e dal vostro inventario.