IT
HqcLethe trasmette chiavi HQC senza memoria per client
HqcLethe: Streaming HQC Encapsulation for Tiny Stateless Servers · arXiv:2610.36808
In parole semplici
HQC è un modo con cui due parti possono creare una chiave segreta condivisa. Le sue chiavi pubbliche sono troppo grandi per un singolo pacchetto di rete e salvare i frammenti incompleti per ogni client potrebbe permettere agli aggressori di esaurire la memoria del server.
HqcLethe consente al server di elaborare piccoli frammenti e dimenticare ogni richiesta, mentre il client assembla le risposte. Una dimostrazione formale verifica che le risposte non rivelino più informazioni di un normale testo cifrato HQC. Su un Raspberry Pi, la memoria misurata è rimasta costante nei carichi di client testati.
La ricerca
Come può un server accettare una chiave pubblica HQC che occupa più pacchetti di rete senza riservare memoria per ogni scambio incompleto?
Memorizzare quei frammenti può permettere a un aggressore di esaurire la memoria del server, mentre la moltiplicazione di polinomi di HQC non si può dividere in semplici frammenti corrispondenti dell’ingresso e del risultato.
HqcLethe trasmette l’incapsulamento delle chiavi HQC in frammenti grandi quanto un pacchetto, così un server senza stato evita memoria per client mentre il client ricostruisce il testo cifrato.
Per valutare i costi del progetto, gli autori hanno confrontato HqcLethe con McTiny, un precedente metodo di scambio di chiavi senza stato, e ne hanno misurato l’uso della memoria su un Raspberry Pi 3B+.
Alla categoria 5, su un host x86, HqcLethe ha usato 27 volte meno byte nel payload UDP e 9.5 volte meno CPU del server per scambio rispetto a McTiny. Sul Raspberry Pi, il limite minimo di memoria necessario a completare le sessioni è stato di 1.2–1.6 MiB nei livelli HQC e nei carichi testati, compresi 64 client.
Questi risultati supportano l’efficienza e la memoria costante in quelle configurazioni, ma il confronto delle prestazioni riguarda protocolli e scelte crittografiche diversi.
Le misure delle prestazioni provengono da un solo host x86 e confrontano progetti diversi, quindi non isolano l’effetto del solo streaming.
Il risultato sulla memoria riguarda i carichi testati su Raspberry Pi; HqcLethe non impedisce la saturazione del collegamento di rete e la sua integrazione in un protocollo completo è ancora un lavoro futuro.
Cosa mostrano le prove
- Il problema della memoria
HqcLethe è un metodo di scambio di chiavi tra un client e un server che non conserva stato per client. HQC è un meccanismo di incapsulamento delle chiavi: permette al server di creare una chiave segreta condivisa e un testo cifrato a partire dalla chiave pubblica del client.
Il problema è che le chiavi pubbliche HQC occupano più pacchetti. Se il server memorizza gli scambi incompleti, un aggressore può costringerlo ad allocare memoria per molti client.
L’articolo chiede come usare HQC senza far crescere la memoria del server in base alle connessioni incomplete.
- Trasmettere i calcoli a frammenti
HqcLethe suddivide la moltiplicazione di polinomi del server in calcoli su resti grandi quanto un pacchetto, usando il teorema cinese del resto. Il server restituisce resti mascherati senza conservare stato per client e il client ricostruisce il testo cifrato.
Così il lavoro viene distribuito diversamente: il server può dimenticare ogni richiesta, mentre il client raccoglie i frammenti necessari per ottenere il risultato.
- Verificare le maschere
I resti grezzi rivelerebbero valori intermedi che non compaiono in un normale testo cifrato HQC. HqcLethe li maschera in modo che scompaiano quando il client ricostruisce e riduce il risultato.
Una dimostrazione meccanizzata in Rocq/SSProve stabilisce che, secondo le ipotesi dichiarate sui moduli, nessun distinguitore può distinguere la procedura con resti mascherati da un simulatore che usa la normale cifratura HQC.
- Confrontare progetti senza stato
Gli autori hanno confrontato HqcLethe con McTiny, un precedente scambio di chiavi senza stato basato su Classic McEliece. Alla categoria 5, sullo stesso host x86, HqcLethe ha usato 27 volte meno byte nel payload UDP complessivo e 9.5 volte meno CPU del server per scambio.
Il confronto riguarda progetti e scelte crittografiche diversi, quindi non mostra quale singola modifica abbia causato la differenza.
- Valutare il compromesso
Un confronto separato con un server con stato che memorizza i frammenti rende visibile il costo dell’assenza di stato: alla categoria 5, HqcLethe ha usato circa il doppio dei byte e 4.1 volte la CPU del server per sessione.
Su un Raspberry Pi 3B+, il limite di memoria misurato è rimasto tra 1.2 e 1.6 MiB nei livelli HQC e nei carichi testati, compresi uno e 64 client. Questi risultati di implementazione supportano il progetto nei sistemi di prova riportati.
Dettagli
- Autori del paper originale
- Wind Wong, Klaus v. Gleissenthall
- Inviato ad arXiv
- Licenza
- CC BY 4.0