Prestazioni della crittografia post-quantistica

Ho già scritto molto sull'impatto della crittografia post-quantistica sulle prestazioni di rete (link qui sotto). Ho comunque pensato che valesse la pena scrivere un altro articolo per riassumere la situazione attuale, fornire ulteriori informazioni e riferimenti e, magari, trarre qualche conclusione.

In sintesi: sebbene le primitive post-quantistiche come ML-KEM e ML-DSA comportino un overhead di CPU gestibile, le dimensioni molto maggiori delle loro chiavi pubbliche e firme rappresentano un serio problema di payload per le reti reali. Far passare questi volumi di dati più grandi attraverso i protocolli di trasporto causa frammentazione, supera le finestre di congestione iniziali standard e provoca round trip aggiuntivi che peggiorano direttamente la velocità di connessione.

Questo articolo fa parte di una serie. Non è necessario aver letto tutte le puntate precedenti, ma ti consiglio di leggere queste due per il contesto che forniscono:

• Effetto degli algoritmi post-quantistici sulle prestazioni di rete
• Perché le firme post-quantistiche superano i limiti dell’handshake TLS

Questi due articoli si concentrano sulla teoria, ma noterai che non forniscono molte prove. Cosa dicono l'industria e il mondo accademico?

Chrome è stato il primo browser a implementare X25519MLKEM768 (un nuovo meccanismo ibrido di scambio delle chiavi resistente ai computer quantistici), quindi ha senso partire da lì. Cosa si osserva nella pratica?

"Chrome ha registrato un aumento del 4% della latenza dell'handshake TLS quando ha implementato ML-KEM, che occupa circa 1 KB di spazio aggiuntivo nel ClientHello. Questo ha portato la dimensione del ClientHello oltre la maximum transmission unit (MTU) standard dei pacchetti su Internet, circa 1.400 byte, causando la frammentazione del ClientHello su due pacchetti del livello di trasporto sottostante (TCP o UDP)."

— David Adrian, da Post-quantum cryptography is too damn big

Sullo stesso tema, Cloudflare ha pubblicato diversi articoli interessanti sulla crittografia post-quantistica. Invece di cercare la risorsa migliore, ecco un link all'intera categoria. Per farti risparmiare tempo: i loro risultati sono in linea con quelli di Google. Payload più grandi portano a frammentazione TCP, maggiore probabilità di perdita di pacchetti e ritardi di connessione misurabili sulle reti reali.

Quando si introducono nuovi payload crittografici ed estensioni di protocollo nel mondo reale, ci si scontra subito con l'ossificazione dei middlebox: apparati di rete e dispositivi di ispezione di sicurezza che interrompono le connessioni semplicemente perché incontrano strutture o dimensioni di dati per cui non sono stati programmati.

Man mano che Google, Cloudflare, Meta e AWS hanno ampliato l'adozione dell'accordo di chiavi post-quantistico, è emersa una serie di problemi operativi specifici:

• Malfunzionamenti di middlebox e firewall: gli apparati di rete e i gateway di sicurezza scartano spesso i messaggi ClientHello frammentati su più pacchetti o rifiutano estensioni TLS sconosciute. I firewall Sophos con le modalità di ispezione della protezione web attive hanno storicamente avuto difficoltà con gli handshake post-quantistici dei client. Allo stesso tempo, gli utenti di AWS Network Firewall hanno riscontrato bug nel rule matching durante la gestione degli handshake PQC con OpenSSL 3.5.1.
• Discrepanze nelle implementazioni su larga scala: nell'implementazione TLS reale di Meta (TLS-PQR), anche tassi di intolleranza minimi si sono tradotti in milioni di connessioni utente coinvolte. Allo stesso modo, i rollout PQC più ampi di Cloudflare (pqc-to-origin e post-quantistico per tutti) hanno evidenziato che i percorsi edge-origin e client-edge incontrano ambienti di middlebox molto diversi.
• Casi limite di frammentazione estrema: quando la MTU del percorso di rete scende sotto gli standard abituali o quando gli handshake UDP/QUIC raggiungono limiti di amplificazione rigidi, i messaggi PQC di grandi dimensioni innescano loop di scarto, un fenomeno documentato in dettaglio da progetti di ricerca come tldr.fail.

I client che vogliono comunicare con server che non offrono X25519 o X25519MLKEM768 dovranno inviare un HelloRetryRequest. In futuro, questo potrebbe riguardare i client che vogliono usare uno scambio di chiavi basato esclusivamente su ML-KEM, imponendo un round trip di rete aggiuntivo ogni volta che il key share previsto dal client non corrisponde alle capacità del server.

Nel frattempo, stiamo osservando problemi simili con gli origin delle CDN: se un origin non supporta i metodi di scambio delle chiavi più diffusi, è necessario un round trip aggiuntivo per completare l'handshake. Cloudflare dispone di dati interessanti, non disponibili altrove, su cosa preferiscono gli origin per lo scambio delle chiavi. Nella ricerca Automatic Key Exchange for Origins, mostrano come la negoziazione automatica e dinamica delle preferenze di scambio delle chiavi eviti i round trip di HelloRetryRequest, molto penalizzanti per le prestazioni, tra i nodi edge e gli origin upstream.

Non vediamo ancora questo problema, perché le catene di certificati post-quantistiche sono rare. Dove vengono usate, lo sono su reti private (più veloci) e da client che hanno maggiore controllo sulle impostazioni di rete e possono ottimizzare i propri stack TCP.

Tuttavia, la ricerca accademica offre un'anteprima chiara di ciò che potrebbe accadere quando l'autenticazione post-quantistica arriverà nella Web PKI pubblica:

• Catene di certificati e throughput dell'handshake: un approfondito studio sulle prestazioni di Sikeridis et al. (NDSS 2020) ha valutato i candidati di firma PQC del NIST all'interno di catene di certificati TLS 1.3. Ha scoperto che usare un unico schema di firma PQC di grandi dimensioni lungo tutta la catena degrada gravemente throughput e latenza del server. Per mitigare il problema, gli autori hanno proposto catene di certificati miste (che combinano algoritmi veloci ma più grandi, come Falcon, con algoritmi più piccoli ma più lenti, come Dilithium o SPHINCS+), che accelerano notevolmente gli handshake e ripristinano i tassi di connessione.
• Latenza di rete vs colli di bottiglia della CPU: Benchmarking post-quantum cryptography in TLS di Paquin, Stebila e Tam (Microsoft Research), grazie a un framework di emulazione di rete, ha dimostrato che il tempo di calcolo della CPU raramente è il principale collo di bottiglia del TLS post-quantistico. Sono invece la latenza di rete e la perdita di pacchetti a dominare i tempi complessivi di caricamento delle pagine, a causa delle dimensioni stesse delle chiavi pubbliche e dei testi cifrati post-quantistici.
• TTFB e TTLB in condizioni di rete reali: la ricerca di Kampanakis e Childs-Klein (MADWeb 2024) ha valutato l'intero ciclo di vita della connessione, il Time-To-First-Byte (TTFB) e il Time-To-Last-Byte (TTLB). Ha rilevato che, sebbene le catene di certificati PQC ricche di dati aumentino la latenza iniziale dell'handshake del 20–30% su collegamenti puliti, il loro impatto relativo viene ampiamente ammortizzato quando si trasferiscono grandi payload di dati o su connessioni già degradate o soggette a perdite.
• Microbenchmark white-box e black-box: Sosnowski et al. (ACM CoNEXT '23) hanno dimostrato che, sebbene lo scambio di chiavi basato su reticoli venga eseguito più velocemente degli algoritmi classici sulla CPU, le dimensioni maggiori di chiavi e catene di certificati aumentano la latenza a livello di rete sui percorsi soggetti a perdite.

Passando dai browser desktop e dai potenti server edge ai moduli di sicurezza hardware (HSM), ai microcontrollori IoT e ai sistemi embedded, l'elevato ingombro di memoria e le dimensioni dei pacchetti della PQC impongono severi vincoli fisici.

I protocolli IoT standard (come CoAP, DTLS ed EDHOC) operano su reti wireless a basso consumo e soggette a perdite, dove i buffer dei pacchetti si misurano in kilobyte. Memorizzare e riassemblare chiavi pubbliche o firme PQC di diversi kilobyte porta rapidamente all'esaurimento dei buffer, a loop di perdita dei frammenti e a un forte consumo della batteria. Inoltre, HSM e smart card devono fare i conti con limiti stringenti di memoria non volatile e con una banda limitata del bus interno quando gestiscono materiale crittografico PQC ed elaborano pesanti firme del firmware OTA (Over-The-Air).

L'IETF sta sviluppando attivamente soluzioni tecniche per adattare gli ambienti con risorse limitate ai requisiti post-quantistici:

• RFC 9958: Post-Quantum Cryptography for Engineers: pubblicato dal gruppo di lavoro PQUIP, questo documento fornisce linee guida operative, compromessi sulle prestazioni e criteri di selezione degli algoritmi per stack di rete con risorse limitate.
• draft-ietf-pquip-pqc-hsm-constrained: affronta i limiti delle risorse hardware fisiche, descrivendo come i vincoli di stato, RAM e NVRAM in HSM, smart card e microcontrollori embedded influiscano sull'archiviazione delle chiavi PQC, sui tempi di elaborazione e sugli aggiornamenti del firmware.
• draft-rfcxml-pqc-key-fragmentation: analizza i rischi di riassemblaggio a livello di rete e fornisce raccomandazioni per prevenire l'esaurimento dei buffer e i loop di perdita dei pacchetti durante la trasmissione di chiavi PQC frammentate su reti wireless a basso consumo (CoAP, DTLS, EDHOC, OSCORE).
• Firme compatte e stateful: linee guida per l'adozione di schemi di firma hash-based stateful (come LMS e XMSS, definiti in RFC 8554 / RFC 8708) per mantenere il codice e l'overhead di verifica delle firme abbastanza leggeri per i bootloader embedded.

Abbiamo molti problemi, ma le prestazioni di calcolo non sono tra questi. I moderni algoritmi PQC basati su reticoli, in particolare ML-KEM e ML-DSA, sono veloci dal punto di vista computazionale. Sui moderni processori x86 e ARM, la generazione delle chiavi, l'incapsulamento e il decapsulamento basati su reticoli richiedono spesso meno cicli di CPU rispetto ai tradizionali scambi ECDH o RSA. Per fortuna, almeno di questo non dobbiamo preoccuparci, a meno che in futuro non decidiamo di passare ad altri algoritmi.

Nonostante questi ostacoli strutturali, diversi benchmark empirici sostengono che il TLS post-quantistico non metterà in ginocchio Internet e che potrebbe persino migliorare le prestazioni dove meno ce lo aspettiamo:

• La superiorità computazionale compensa i byte: Sosnowski et al. (ACM CoNEXT '23) hanno dimostrato che, poiché le primitive basate su reticoli (ML-KEM) richiedono molti meno cicli di CPU rispetto alle curve classiche ad alta sicurezza o a RSA, il throughput complessivo del server può addirittura aumentare in normali condizioni di rete.
• I microcontrollori possono essere più veloci con la PQC: Gillot, Buchanan e Turino (arXiv:2610.27766) hanno messo direttamente in discussione l'idea che l'hardware IoT avrebbe ceduto sotto il peso dei payload PQC. Testando decine di configurazioni TLS 1.3 su microcontrollori con risorse limitate (come il Raspberry Pi Pico W), hanno scoperto che le operazioni matematiche a basso numero di cicli di ML-KEM permettevano agli handshake TLS post-quantistici di completarsi molto più rapidamente (fino al ~41% più veloci nei benchmark) rispetto agli handshake classici tradizionali, dimostrando che i dispositivi embedded possono eseguire senza difficoltà uno scambio di chiavi quantum-safe.
• Ammortamento del payload nel traffico reale: la ricerca di Kampanakis e Childs-Klein (MADWeb '24) evidenzia che, sebbene la latenza dell'handshake PQC aumenti se considerata isolatamente, diventa statisticamente trascurabile se valutata rispetto al Time-to-Last-Byte (TTLB) reale e ai payload HTTP tipici (>40 KB).
• Soluzioni architetturali come KEMTLS: la ricerca di Schwabe, Stebila e Wiggers (ACM CCS '20) dimostra che l'autenticazione non richiede necessariamente firme di diversi kilobyte: sostituire le firme dell'handshake con i KEM (AuthKEM) mantiene il volume di byte dell'handshake ben entro i limiti standard della finestra TCP.