Uno sguardo più approfondito alle prestazioni di ML-KEM

Questo articolo del blog fa parte di una serie in cui affronto la migrazione post-quantistica dal punto di vista tecnico. Il nostro obiettivo è capire quali problemi vanno affrontati, e come e perché vengono prese determinate decisioni. In fondo, si tratta di capire. I primi due articoli hanno trattato le sfide legate all'aumento delle dimensioni delle firme e ai nuovi metodi di scambio di chiavi. Nel terzo, abbiamo esaminato i livelli di rete e il protocollo TLS per scoprire quali aspetti influenzano le prestazioni e come questi saranno interessati dalla migrazione.

In questo quarto articolo, esaminiamo le nuove opzioni di scambio di chiavi che coinvolgono ML-KEM per capire come si comportano in pratica. Questa è la parte della migrazione post-quantistica già implementata, almeno nel protocollo TLS. Le decisioni sono state prese, vediamo dunque come hanno influito sulle prestazioni sulla rete.

Prima di intraprendere la migrazione post-quantistica, TLS 1.3 offriva due opzioni per lo scambio di chiavi, entrambe basate sull'algoritmo Diffie-Hellman; una classica e l'altra con curve ellittiche. Le chiamiamo solitamente DHE e ECHDE. (L'ultima "E" dell'abbreviazione sta per ephemeral, ossia effimero. È un vantaggio, perché garantisce la forward secrecy.) ECHDE era ed è tuttora l'opzione dominante, grazie a migliori proprietà di sicurezza con chiavi più piccole, prestazioni migliori e minori requisiti di storage sulla rete.

Con la migrazione post-quantistica, TLS è passato allo scambio di chiavi ibrido, che combina ECDHE con lo standard ML-KEM adottato dal NIST. Poiché si tratta di un ibrido, ogni handshake TLS trasporta informazioni su due algoritmi; facciamo letteralmente tutto due volte. Che impatto ha avuto sul protocollo?

Per scoprirlo, ho ripreso in mano un mio vecchio strumento (un fork di un lavoro precedente di Vincent Bernat) che avevo già usato per questo tipo di misurazione. L'ho portato su OpenSSL 3.5.5, incluso in Ubuntu 26.04 LTS. Questa versione di OpenSSL [o giù di lì] equipaggia attualmente i sistemi operativi LTS più recenti.

Il mio strumento è progettato per misurare i requisiti di CPU e di trasporto di rete di varie suite di cifratura, algoritmi di scambio di chiavi e protocolli. In questo caso, ho scelto di testare quattro opzioni:

• Chiave ECDSA-256 abbinata a ECDHE-X25519 – la baseline, un'opzione moderna e veloce.
• Chiave RSA-2048 abbinata a ECDHE-X25519 – leggermente più lenta a causa di RSA.
• Chiave ECDSA-256 abbinata a X25519MLKEM768 – la nuova opzione ibrida PQC.
• Chiave ECDSA-256 abbinata a ML-KEM-1024 – la nuova opzione PQC pura.

Possiamo testare solo TLS 1.3, perché TLS 1.2 e versioni precedenti non saranno adattate alla crittografia post-quantistica.

La misurazione viene effettuata sullo stesso computer, facendo girare un client completo e un server completo, nello stesso processo ma su thread separati. Misuriamo il consumo di CPU e monitoriamo la dimensione di ogni handshake. Ogni esecuzione ha effettuato 2.000 handshake ed è stata ripetuta 3-5 volte per stabilizzare i valori. Da notare che le misurazioni di CPU rappresentano il tempo di CPU, il che è sufficiente per confrontare uno scambio di chiavi con un altro, ma questi valori non sono altrimenti comparabili con misurazioni effettuate altrove.

Diamo prima un'occhiata all'utilizzo della CPU durante lo scambio di chiavi.

Si vede subito perché ECDSA è attualmente l'algoritmo di chiave preferito rispetto a RSA. Con quest'ultimo, il server deve svolgere 2,5 volte più lavoro a ogni handshake. C'è anche una notevole asimmetria nel tempo di CPU impiegato da client e server: i server svolgono complessivamente 3 volte più lavoro.

Ho incluso RSA solo per contrasto ma, ai nostri fini, possiamo escludere questa misurazione e concentrarci sulle altre tre, che usano tutte ECDSA. Il verdetto? Non ci sono differenze significative nel tempo di CPU, indipendentemente dallo scambio di chiavi usato. Questo perché ML-KEM è molto veloce. Sebbene ci siano incrementi relativi non banali, in termini assoluti le differenze sono minime.

Esaminiamo ora la quantità di dati scambiati tra client e server.

Qui vediamo differenze significative. Confrontando le due misurazioni ML-KEM con X25519 come baseline, vediamo che X25519MLKEM768 aggiunge 1.176 byte all'handshake lato client e 1.088 byte lato server. Delle due, l'aumento lato server (2x) è più significativo, perché occupa spazio nella finestra di congestione iniziale, che rappresenta il collo di bottiglia che incontreremo in pratica.

ML-KEM-1024, un algoritmo più robusto, occupa ancora più spazio. Il lato server dell'handshake aumenta di 1.537 byte, ossia circa 2,6 volte di più.

Come forse ricorderete dai miei articoli precedenti, usiamo ML-KEM-1024 per la misurazione ML-KEM pura perché è il minimo accettato dalla NSA nell'ambito del loro requisito Commercial National Security Algorithm (CNSA) 2.0.

Queste misurazioni non raccontano tutta la storia, perché client e server girano entrambi sulla stessa macchina, con una latenza di rete minima. Anche a questo livello, vediamo che ML-KEM puro è leggermente peggiore rispetto agli altri metodi; richiede più o meno la stessa CPU, ma più byte nell'handshake.

In pratica, dobbiamo considerare che i client TLS possono inviare solo un numero limitato di key share nel loro ClientHello iniziale. Oggi vengono inviati X25519 e X25519MLKEM768, ma non ML-KEM-1024. Questo significa che ogni server che desidera quest'ultima opzione deve rispondere con una richiesta di nuovo tentativo a ogni singola connessione TLS completa, il che aggiunge un ulteriore round trip all'handshake.

Aggiungere ML-KEM-1024 come terzo key share per impostazione predefinita non ha molto senso, dato che la maggior parte del mondo non lo userà. Per ora, i server che necessitano di un'opzione PQC pura dovranno accettare la penalità di prestazioni.

Questo probabilmente non sarà un problema sulle reti locali, dove i round trip si misurano in pochi millisecondi, ma la penalità di prestazioni sarà decisamente percepibile su Internet pubblico. Se sapessimo quali scambi di chiavi sono supportati da un determinato server, potremmo inviare un solo key share, ma al momento non disponiamo della tecnologia per distribuire questa informazione. Una RFC attualmente in corso ("TLS Key Share Prediction") esplora l'uso del DNS a questo scopo, tramite i record SVCB e HTTPS.