Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

Questo studio presenta un'analisi sperimentale su più livelli dell'impatto degli algoritmi crittografici post-quantum (ibridi e puri) rispetto a quelli tradizionali sulle prestazioni delle transazioni HTTP su TLS 1.3, valutando le prestazioni dalla fase di handshake TCP fino al livello applicativo HTTP.

L'essenziale

Ecco una spiegazione semplice e creativa di questo studio, pensata per chiunque, anche senza competenze tecniche.

Immagina di dover inviare una lettera importante a un amico. Per farlo, devi prima costruire un corriere speciale (il protocollo TLS) che garantisca che nessuno possa leggere o rubare il contenuto. Fino a poco tempo fa, questo corriere usava una serratura classica (crittografia tradizionale). Oggi, però, si teme che in futuro arriveranno dei "ladri super-intelligenti" (i computer quantistici) capaci di forzare quelle vecchie serrature in un batter d'occhio.

Per proteggersi, gli scienziati hanno inventato nuove serrature "anti-ladro" (crittografia post-quantistica o PQC). Ma c'è un dubbio: queste nuove serrature sono così pesanti e complicate da rallentare il corriere?

Questo studio risponde a questa domanda analizzando il viaggio della lettera "strato per strato", come se fosse un'analisi medica dettagliata.

1. Il Laboratorio: Una Corsa a Ostacoli

Gli autori hanno creato un laboratorio virtuale dove hanno fatto correre 100 corrieri al secondo (una velocità molto alta per un test) verso un server. Hanno testato tre tipi di corrieri:

• Il Classico: Usa la vecchia serratura sicura (x25519).
• Ibrido: Indossa sia la vecchia serratura che una nuova, per sicurezza doppia (come mettere due catene alla porta).
• Puro Post-Quantistico: Usa solo la nuova serratura avanzata (ML-KEM).

Hanno anche variato il "peso" del pacco: una lettera leggera (4 KB) e una pesante (40 KB).

2. L'Analisi a Strati: Dove si perde tempo?

Invece di guardare solo quanto tempo impiega l'intero viaggio, gli autori hanno diviso il tempo in 5 tappe, come se analizzassero ogni singolo passo del corriere:

1. Il Saluto (TCP Handshake): È il momento in cui il corriere bussa alla porta e dice "Ciao, sono qui".

   • Risultato: Nessuna differenza. Che tu usi la serratura vecchia o quella nuova, il "bussare" richiede lo stesso identico tempo. Il corriere non sa ancora quale serratura userà.

2. La Preparazione (TCP-to-TLS Delay): È il momento in cui il corriere si prepara, controlla gli attrezzi e costruisce la richiesta di apertura.

   • Risultato: Qui c'è il vero "colpo di tosse". Quando si usano le nuove serrature (PQC), questa fase diventa 6 volte più lenta rispetto al passato. È come se il corriere, invece di avere le chiavi in tasca, dovesse prima costruire la chiave con un martello. È il costo principale: si paga per prepararsi, non per viaggiare.

3. Lo Scambio delle Chiavi (TLS Handshake): È il momento in cui il corriere e il destinatario si scambiano le chiavi e si assicurano che tutto sia sicuro.

   • Risultato: Sorprendentemente, è uguale! Contrariamente a quanto molti pensavano, la fase di scambio vero e proprio delle chiavi nuove non è più lenta di quella vecchia. Anzi, le nuove serrature sono così efficienti che, in teoria, dovrebbero essere veloci, ma nella pratica il tempo è così simile che non si nota alcuna differenza. È come se due corrieri, uno con una bici e uno con una moto, arrivassero allo stesso tempo al casello perché il traffico è lo stesso.

4. L'Arrivo e la Consegna (Application Layer): È il momento in cui il pacco viene aperto e consegnato.

   • Risultato: Nessuna differenza. Una volta aperta la porta, consegnare una lettera leggera o pesante richiede lo stesso tempo, indipendentemente da quale serratura hai usato prima.

3. Le Scoperte Chiave (in parole povere)

• Il "Costo" è tutto all'inizio: Il rallentamento dovuto alle nuove tecnologie di sicurezza è concentrato quasi interamente nel momento in cui il corriere si prepara (la fase 2). Una volta iniziata la conversazione sicura, il viaggio è fluido.
• L'effetto "Pacco Grande": Se il pacco da consegnare è molto grande (40 KB invece di 4 KB), il tempo totale aumenta perché il pacco è pesante. Tuttavia, il tempo "perso" per la nuova serratura rimane lo stesso. Quindi, più grande è il pacco, meno si nota il rallentamento della serratura. È come se il costo di un biglietto del treno fosse lo stesso, ma se viaggi con un carico enorme, il costo del biglietto diventa una percentuale minima del totale.
• Il carico sul computer: Usare le nuove serrature raddoppia il lavoro che il computer del mittente (il client) deve fare per preparare la chiave. Il server (il destinatario) lavora un po' di più, ma non in modo drammatico. Tuttavia, per dispositivi piccoli come smartphone o sensori IoT, questo doppio sforzo potrebbe essere un problema.

4. La Conclusione: Vale la pena?

La risposta è Sì.

Anche se le nuove serrature richiedono un po' di tempo extra per essere "costruite" all'inizio (circa 3-4 millisecondi in più su un viaggio totale di 20 millisecondi), questo rallentamento è trascurabile per l'utente finale. Non noterai che il sito web è più lento.

Inoltre, il tempo extra rappresenta solo una piccola percentuale (tra il 6% e il 14%) del tempo totale di connessione. È come se dovessi aspettare 3 secondi in più in fila alla posta per avere la certezza assoluta che nessuno aprirà mai la tua lettera in futuro. È un piccolo prezzo da pagare per la sicurezza.

In sintesi: Le nuove tecnologie di sicurezza quantistica sono pronte. Non sono "pesanti" come si temeva; rallentano solo il momento della preparazione, ma una volta in viaggio, sono veloci quanto le vecchie. Il futuro è sicuro e, fortunatamente, non ci farà aspettare troppo.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del documento "Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange", presentato in italiano.

1. Problema e Contesto

L'avvento dei computer quantistici crittograficamente rilevanti minaccia le infrastrutture a chiave pubblica attuali, rendendo necessario un passaggio verso la crittografia post-quantistica (PQC). Con la standardizzazione finale delle normative NIST (FIPS 203, 204, 205) nel 2024, le organizzazioni devono migrare verso algoritmi resistenti al quantum (come ML-KEM) per prevenire attacchi "store now, decrypt later".

Tuttavia, prima del deployment in produzione, è cruciale quantificare l'impatto prestazionale di questi nuovi algoritmi. Studi precedenti hanno spesso valutato la PQC solo a livello aggregato (tempo totale di handshake), senza decomporre il flusso di dati. Questo approccio nasconde dove si generano esattamente i ritardi, rendendo difficile l'ottimizzazione mirata. Il problema centrale è determinare se e quanto gli algoritmi PQC (ibridi o puri) degradino le prestazioni di TLS 1.3 in scenari di carico reale e identificare quali strati del protocollo ne siano affetti.

2. Metodologia Sperimentale

Gli autori hanno condotto uno studio di laboratorio che simula un ambiente di produzione reale, analizzando le transazioni HTTP su TLS 1.3 attraverso una decomposizione a cinque livelli.

• Architettura di Test:

  • Client: Generatore di traffico stato-consapevole Keysight CyPerf, capace di emulare migliaia di handshake TLS al secondo.
  • Server: Nginx 1.27.3 come reverse proxy, compilato con OpenSSL 3.4.0 integrato con la libreria OQS (Open Quantum Safe) per supportare algoritmi PQC.
  • Backend: Un agente CyPerf che risponde a richieste HTTP con dimensioni variabili.
  • Carico: 100 transazioni al secondo (TPS) per 5 minuti (circa 30.000 richieste per test, totale ~1 milione di richieste).

• Configurazioni Crittografiche:

  • Classico: x25519 (ECDH).
  • Ibrido: x25519 + ML-KEM (512 e 768 bit).
  • Puro PQC: ML-KEM (512 e 1024 bit).
  • Variabili: Dimensione del corpo di risposta del backend (Diretta, 4 KB, 40 KB).

• Strumento di Analisi:

  • È stato sviluppato uno strumento di riduzione dati (pcap_layer_analysis.py) che decifra i pacchetti catturati (usando i log delle chiavi SSL) per misurare i tempi di latenza tra specifici punti di confine del protocollo:
    1. TCP Handshake (SYN → SYN-ACK).
    2. Ritardo TCP-TLS (SYN-ACK → ClientHello).
    3. Handshake TLS (ClientHello → Finished).
    4. Ritardo TLS-App (Finished → HTTP GET).
    5. Risposta Applicativa (HTTP GET → HTTP 200 OK).

• Metriche Statistiche:

  • Analisi di percentili (p50, p90, p95, p99) e deviazione standard.
  • Calcolo dell'Effetto Glass's Δ per determinare la significatività pratica delle differenze (soglia di Cohen: <0.2 trascurabile, >0.8 grande).

3. Contributi Chiave

1. Metodologia a 5 Livelli: Una nuova decomposizione della latenza end-to-end che permette di attribuire l'overhead PQC a fasi specifiche del protocollo, superando le analisi aggregate.
2. Dataset Pubblico: Disponibilità di catture di pacchetti TLS decifrati e log delle chiavi per garantire la riproducibilità degli esperimenti.
3. Scoperta sull'Neutralità dell'Handshake: Dimostrazione empirica che lo strato di handshake TLS è sostanzialmente "neutrale" rispetto all'algoritmo di scambio chiavi.
4. Strumento di Analisi: Pubblicazione di uno script Python per l'estrazione automatica delle statistiche per livello dai file pcap.

4. Risultati Principali

A. Decomposizione della Latenza per Livello

• TCP Handshake: Indipendente dall'algoritmo crittografico. Le differenze sono trascurabili (Δ < 0.2). Eventuali variazioni a coda (p95) sono dovute al carico di sistema, non alla crittografia.
• Ritardo TCP-TLS (Inizializzazione Client): Questo è il livello dominante dell'overhead PQC.
  • La latenza mediana aumenta da ~0,3 ms (x25519) a ~1,8-1,9 ms (PQC).
  • Si osserva un fattore di sovraccarico di circa 6x (Glass's Δ ≈ 7,7, effetto molto grande).
  • La causa è la generazione del materiale chiave e la costruzione del ClientHello lato client.
• Handshake TLS (Negoziazione): Sorprendentemente, non mostra differenze pratiche significative.
  • Le differenze tra classico, ibrido e puro PQC sono minime (0,1-0,9 ms) e statisticamente trascurabili (Δ < 0,33).
  • Anche se i micro-benchmark mostrano che ML-KEM è computazionalmente efficiente, a livello di protocollo TLS questi vantaggi sono assorbiti dal framing, dal jitter di rete e dallo scheduling del sistema.
  • Conclusione: L'handshake TLS è algoritmo-neutrale in questo scenario di carico.
• Livello Applicativo: La latenza di risposta è dominata dalla dimensione del payload e dal percorso di rete. L'impatto della PQC è trascurabile (Δ < 0,2).

B. Impatto del Payload (4 KB vs 40 KB)

• L'aumento della dimensione della risposta (da 4 KB a 40 KB) non influisce sui livelli crittografici (TCP-TLS, Handshake, TLS-App rimangono costanti).
• L'overhead PQC assoluto rimane costante (~2,3 ms), ma il suo impatto relativo diminuisce (diluzione): passa dal ~15% al ~8% del tempo totale di transazione.

C. Utilizzo delle Risorse (CPU e Rete)

• CPU Client: Raddoppia sotto PQC (da ~3,7% a ~8,5%), indicando un costo significativo per dispositivi con risorse limitate (IoT, mobile).
• CPU Server: Aumenta leggermente in termini assoluti (~14-15%), ma in termini relativi l'aumento è del ~6% per le configurazioni ibride.
• Traffico di Rete: Aumenta linearmente con la dimensione delle chiavi (da 32 byte a ~1568 byte), ma non ha un impatto proporzionale sulla latenza nella topologia testata.

D. Overhead Normalizzato

• Nonostante il forte impatto sul livello TCP-TLS, la Cryptographic Overhead Share (COS) totale rappresenta solo il 6-14% del tempo di connessione end-to-end.
• Le configurazioni ibride hanno una COS leggermente più alta (10-14%) rispetto al PQC puro (6-8%), principalmente a causa della somma dei costi ECDH e KEM, ma la differenza non è statisticamente significativa nel livello di handshake.

5. Significato e Conclusioni

Lo studio fornisce rassicurazioni critiche per la migrazione alla PQC:

1. Nessun Penalty nell'Handshake: Contrariamente alle aspettative, l'uso di ML-KEM (puro o ibrido) non introduce un ritardo misurabile durante la fase di negoziazione TLS rispetto a x25519.
2. Costo Concentrato: L'unico costo significativo e sistematico è la fase di inizializzazione lato client (generazione chiavi), che raddoppia l'uso della CPU e aumenta la latenza di circa 1,5 ms prima dell'inizio dell'handshake.
3. Impatto Pratico Limitato: In scenari reali con payload di dati, l'overhead PQC diventa una frazione sempre più piccola del tempo totale di transazione.
4. Implicazioni per i Dispositivi di Rete: Per dispositivi che agiscono come Man-in-the-Middle (MiTM) e devono decifrare/iscrivere/ri-cifrare il traffico, l'impatto potrebbe essere più severo a causa della somma degli overhead lato client e server ad alto carico.

In sintesi, la migrazione a TLS 1.3 con PQC è fattibile con un impatto sulle prestazioni utente finale contenuto (aggiunta di ~3-4 ms totali), ma richiede attenzione alla capacità computazionale dei client e dei dispositivi di sicurezza di rete.