Il NIST sceglie HQC: un secondo algoritmo di cifratura post-quantum di riserva - init.d
EN

# Il NIST sceglie HQC: un secondo algoritmo di cifratura post-quantum di riserva

Alessandro Corbelli~7 min read min
Table of Contents

L’11 marzo 2025 il NIST, l’ente statunitense che definisce molti standard di sicurezza usati in tutto il mondo, ha annunciato la scelta di un nuovo algoritmo di crittografia chiamato HQC. La sigla è ostica, ma la sostanza è semplice: HQC servirà da riserva per proteggere i dati contro una minaccia futura, affiancando un algoritmo già scelto in precedenza. Vale la pena capire cosa vuol dire, contro cosa protegge e perché avere un secondo algoritmo, invece di uno solo, è una decisione sensata.

La notizia in breve

Da alcuni anni il NIST porta avanti un lavoro pubblico per selezionare algoritmi di crittografia post-quantum, cioè metodi di cifratura pensati per resistere anche a un tipo di computer che oggi non esiste ancora in forma utilizzabile. Nel 2024 sono stati pubblicati i primi standard di questa nuova famiglia. Ora se ne aggiunge un altro: HQC, scelto come algoritmo di riserva per la cifratura.

Il punto chiave è proprio la parola “riserva”. HQC non sostituisce nulla. L’algoritmo principale per la cifratura resta ML-KEM, già standardizzato. HQC gli si affianca come seconda opzione, da tenere pronta nel caso in cui il primo dovesse mostrare debolezze in futuro. È il quinto algoritmo che il NIST seleziona in questo percorso, e il secondo dedicato specificamente alla protezione dei dati in transito.

Il problema: la minaccia dei computer quantistici

Per capire perché serva tutto questo bisogna partire dalla minaccia. Oggi buona parte di ciò che facciamo online è protetto da crittografia: quando nel browser compare il lucchetto, i dati scambiati tra il dispositivo e il sito sono resi illeggibili a chi tentasse di intercettarli. Questa protezione regge perché i computer attuali non hanno la potenza per forzarla in tempi ragionevoli.

I computer quantistici sono una tecnologia in sviluppo, basata su principi fisici diversi da quelli dei computer tradizionali. In teoria, una macchina di questo tipo abbastanza potente potrebbe un giorno rompere buona parte della crittografia che usiamo adesso. Nessuno sa con certezza se e quando arriverà quel momento: le stime degli esperti vanno da oltre un decennio a diversi decenni.

C’è però un motivo per non aspettare. Chi intercetta traffico cifrato oggi può archiviarlo e conservarlo, in attesa di poterlo decifrare quando la tecnologia lo permetterà. Questa strategia ha un nome, “raccogli ora, decifra dopo”. Significa che dati destinati a restare sensibili per anni sono già a rischio adesso, anche se la macchina capace di aprirli non esiste ancora. Da qui l’urgenza di adottare per tempo algoritmi resistenti, lo stesso motivo per cui Chrome ha iniziato ad abilitare di default lo scambio di chiavi post-quantum nelle connessioni TLS.

Cos’è HQC e su cosa si basa

HQC sta per Hamming Quasi-Cyclic. È un meccanismo di incapsulamento delle chiavi (in inglese key encapsulation mechanism, abbreviato KEM): in parole povere, si occupa del momento iniziale di una connessione sicura, quando due parti devono mettersi d’accordo su una chiave segreta condivisa senza che nessun altro possa scoprirla. Quella chiave serve poi a cifrare tutto il resto della conversazione. È proprio questo passaggio a essere il più esposto alla strategia “raccogli ora, decifra dopo”, ed è quindi il primo da mettere in sicurezza.

La particolarità di HQC sta nella matematica su cui si fonda. Ogni algoritmo di crittografia moderna si appoggia a un problema matematico che si ritiene molto difficile da risolvere. HQC si basa sui codici correttori d’errore: tecniche nate per individuare e correggere gli errori nei dati quando vengono trasmessi o archiviati, usate da decenni in ambiti come le comunicazioni satellitari, i vecchi CD o i codici QR. Da quel principio si ricava un problema matematico difficile su cui costruire la protezione.

Qui sta la differenza importante rispetto a ML-KEM, l’algoritmo principale. ML-KEM si basa su un’altra area della matematica, chiamata reticoli strutturati (in inglese structured lattices). Due algoritmi, due fondamenta matematiche diverse. Non è un dettaglio da poco, come si vede tra poco.

Perché avere un’alternativa: la crypto-agility

La ragione per cui il NIST ha scelto un secondo algoritmo, e per giunta basato su matematica diversa, è una forma di prudenza. Questi algoritmi sono relativamente recenti. Sono stati studiati a fondo da esperti di tutto il mondo, ma nessuno può escludere del tutto che in futuro venga scoperta una debolezza. La storia della crittografia è piena di metodi ritenuti solidi e poi superati.

Il rischio più insidioso è quello sistemico. Se tutti gli algoritmi disponibili si basassero sullo stesso principio matematico, una singola scoperta capace di incrinare quel principio metterebbe in crisi l’intero sistema in un colpo solo. Avere un’alternativa costruita su fondamenta indipendenti riduce questo pericolo: se un giorno emergesse un problema con i reticoli su cui poggia ML-KEM, resterebbe pronto HQC, che dei reticoli non fa uso. E viceversa. Il responsabile del progetto post-quantum del NIST ha spiegato la scelta proprio così: serve uno standard di riserva basato su un approccio matematico diverso, nel caso in cui il primo dovesse un giorno rivelarsi vulnerabile.

Questo modo di ragionare ha un nome: crypto-agility, cioè la capacità di cambiare algoritmo senza dover ricostruire tutto da zero. Un sistema progettato in modo agile può passare da un metodo di cifratura a un altro con relativa facilità, man mano che le circostanze cambiano. Non è una qualità appariscente, ma è ciò che permette di reagire in fretta se qualcosa va storto, invece di restare bloccati con un’unica soluzione.

A che punto è: tempi e stato

Conviene essere precisi su un punto: la scelta di HQC è l’inizio di un percorso, non la fine. Al momento dell’annuncio non esisteva ancora uno standard pronto all’uso.

Il NIST ha indicato una tabella di marcia. Una bozza di standard è attesa entro circa un anno dall’annuncio, quindi indicativamente nel 2026. Alla pubblicazione della bozza segue un periodo di commenti pubblici di circa 90 giorni, durante il quale chiunque può segnalare problemi o proporre modifiche. Solo dopo si arriva alla versione definitiva, prevista intorno al 2027. Fino a quel momento HQC non è un algoritmo da mettere in produzione, ma una scelta consolidata di cui è stato annunciato il percorso di standardizzazione.

Vale la pena aggiungere un dettaglio tecnico onesto: HQC, a parità di sicurezza, tende a richiedere più risorse di calcolo rispetto a ML-KEM. È uno dei motivi per cui resta la seconda opzione e non la prima. Non è pensato per sostituire l’algoritmo principale nell’uso quotidiano, ma per esistere come alternativa affidabile su basi diverse.

Cosa cambia in pratica

Per la maggior parte delle persone, oggi, non cambia nulla di immediato. Non c’è alcuna azione da compiere e nessun software da aggiornare a mano per via di HQC. La transizione alla crittografia post-quantum è un processo lungo, che avviene soprattutto dietro le quinte, negli aggiornamenti di browser, sistemi operativi e librerie, un processo già misurabile: una parte crescente del traffico web passa già da crittografia post-quantum.

Per chi progetta o gestisce sistemi, invece, c’è un principio da tenere a mente: non concentrare tutto su un solo algoritmo. La lezione di questa notizia è proprio la crypto-agility. Un’infrastruttura pensata per poter cambiare metodo di cifratura in futuro, senza riscrivere mezzo sistema, sarà molto più semplice da adeguare quando gli standard evolveranno, lo stesso principio dietro la scelta di accorciare la vita dei certificati TLS per limitare i danni quando qualcosa va storto. Non serve correre ad adottare HQC oggi, ma conviene costruire in modo da poterlo fare domani senza traumi.

In sintesi

Il NIST ha scelto HQC come algoritmo di cifratura post-quantum di riserva, da affiancare a ML-KEM. La sua caratteristica principale è la matematica su cui si fonda, i codici correttori d’errore, diversa da quella dell’algoritmo principale. Questa diversità è il punto: avere due fondamenta indipendenti rende il sistema più resistente nel tempo, perché una singola scoperta non potrebbe abbatterle entrambe insieme. Lo standard vero e proprio arriverà nei prossimi anni, con una bozza attesa nel 2026 e la versione definitiva verso il 2027. Nel frattempo, la lezione utile a tutti è semplice: nella sicurezza, avere un piano B costruito su basi diverse non è un lusso, è prudenza.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent’anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli