QUIC accelera due tipi di chiave IKEv2, ma le chiavi enormi restano difficili
Embedding Large PQC KEMs in IKEv2 · arXiv:2610.32356
In parole semplici
IKEv2 è un protocollo che crea connessioni di rete sicure, ma non può dividere il primo messaggio della procedura. Alcune chiavi post-quantistiche sono troppo grandi per entrare facilmente in quel messaggio.
Il paper passa in rassegna le proposte esistenti e introduce tre approcci, tra cui l'uso di QUIC, un modo affidabile per trasportare i messaggi di avvio della connessione. Nei test, l'approccio che combina le chiavi in un unico scambio tramite QUIC ha avuto il tempo medio di avvio più breve per due dei tre tipi di chiave testati.
Con le chiavi più grandi, tutti gli approcci hanno incontrato difficoltà sulle reti più impegnative.
La ricerca
Come può IKEv2 trasportare dati voluminosi sulle chiavi post-quantistiche se il suo primo scambio non può essere frammentato a livello di protocollo?
La risposta conta perché le dimensioni delle chiavi variano molto e perché ritardo, larghezza di banda e perdita di pacchetti possono determinare se lo scambio si completa rapidamente o provoca congestione.
Gli autori passano in rassegna le proposte IETF, aggiungono tre approcci al protocollo e confrontano come trasportano le chiavi post-quantistiche su reti difficili.
La domanda centrale è come IKEv2 possa trasportare dati voluminosi sulle chiavi post-quantistiche quando il primo scambio non può usare la frammentazione a livello di protocollo, soprattutto su collegamenti lenti o soggetti a perdite.
Gli autori passano in rassegna le proposte IETF, aggiungono tre approcci e ne confrontano le prestazioni e la capacità di gestire le perdite in condizioni di rete simulate.
Nei test con ML-KEM e FrodoKEM, l'approccio che combina QUIC e un unico scambio ha avuto il tempo medio di handshake più breve tra quelli testati. Le medie aggregano i risultati delle singole configurazioni considerando larghezze di banda e ritardi diversi per ciascun livello di perdita.
Con le chiavi Classic McEliece, però, al peggiorare delle condizioni ogni approccio impiegava in media più di un minuto per handshake oppure congestionava la rete.
I test hanno usato l'autenticazione con chiave precondivisa statica e perdite di pacchetti distribuite casualmente. Non misurano il traffico aggiuntivo dovuto alle firme e alle catene di certificati, né mostrano come si comportino gli approcci in presenza di perdite a raffica.
Cosa mostrano le prove
- Il problema delle chiavi voluminose
Il paper combina una revisione sistematica delle proposte IETF per gli scambi di chiavi post-quantistici in IKEv2, tre nuovi approcci al protocollo e una valutazione comparativa. IKEv2 non può usare il proprio meccanismo di frammentazione nel primo scambio, proprio quando potrebbe essere necessario trasmettere dati voluminosi sulle chiavi.
Gli autori esaminano come i diversi approcci gestiscono questo vincolo e condizioni di rete difficili.
- Tre modi per trasportare le chiavi
I nuovi approcci modificano il modo in cui vengono trasmessi i messaggi di handshake. Uno aggiunge dati ridondanti ai messaggi UDP per aiutare a recuperare quelli persi.
Due usano QUIC, un protocollo di trasporto affidabile, per trasportare i messaggi di handshake di IKEv2; uno dei due riunisce le chiavi classiche e post-quantistiche in un unico scambio. Gli autori confrontano questi approcci con le proposte individuate nella revisione IETF.
- Le chiavi più piccole favoriscono un approccio
Gli autori hanno misurato 1,296 configurazioni variando tipo di chiave, ritardo, larghezza di banda e perdita di pacchetti, mentre il riordino era mantenuto fisso. Il sistema di controllo dei test ha eseguito 126,500 handshake tra due host Linux collegati, simulando condizioni di rete.
Per ML-KEM e FrodoKEM, QUIKE-composite ha registrato la durata media di handshake più breve tra gli approcci testati: per ciascun livello di perdita, le medie dei risultati delle configurazioni sono state aggregate considerando larghezze di banda e ritardi diversi.
- Le chiavi più grandi restano difficili
Questo risultato ha un limite preciso. Con Classic McEliece, al peggiorare delle condizioni di rete, ogni approccio testato impiegava in media più di un minuto per handshake oppure congestionava la rete.
Gli autori riconducono la difficoltà alle dimensioni molto maggiori dei dati delle chiavi: le ritrasmissioni dei datagrammi potevano aumentare la congestione, mentre gli approcci basati sul trasporto rallentavano in risposta alle perdite.
- Le prestazioni comportano compromessi
Per ML-KEM e FrodoKEM, gli autori descrivono la scelta come un compromesso. Le estensioni IKEv2 esistenti preservano continuità e compatibilità, ma potrebbero richiedere ottimizzazioni; cambiare il trasporto può migliorare le prestazioni e semplificare il design, al costo di perdere continuità e introdurre nuove dipendenze.
La configurazione dei test e il perimetro della revisione, limitato alle fonti IETF, restringono la portata di questi risultati.
Dettagli
- Autori del paper originale
- Daniel Herzinger, Marco Thomas, Tobias Handirk, Stefan-Lukas Gazdag, Daniel Loebenberger
- Inviato ad arXiv
- Licenza
- arXiv non-exclusive