L'ANSSI, l'agenzia nazionale francese per la cybersicurezza (Agence nationale de la sécurité des systèmes d'information), non chiede alle organizzazioni di sostituire la crittografia classica con la crittografia post-quantistica. Chiede entrambe contemporaneamente. L'ibridazione, ossia uno scambio di chiavi in cui la chiave di sessione dipende sia da un algoritmo classico sia da un meccanismo di incapsulamento di chiave (KEM) post-quantistico, è obbligatoria nel perimetro regolato dall'ANSSI. Al di fuori di tale perimetro l'ANSSI pubblica raccomandazioni e precisa che queste raccomandazioni non sono ancora obblighi normativi.
Cosa intende l'ANSSI per ibridazione
Un handshake ibrido esegue due scambi di chiavi e combina i due segreti condivisi nella chiave di sessione. Per recuperare il traffico, un attaccante deve violarli entrambi. Questo schema risponde contemporaneamente a due preoccupazioni distinte. La componente classica conserva le garanzie di due decenni di analisi e di implementazioni ampiamente verificate, come X25519 o ECDH sulle curve NIST. La componente post-quantistica, in pratica ML-KEM come standardizzato dal NIST nel FIPS 203 il 13 agosto 2024 (csrc.nist.gov), elimina l'esposizione al rischio harvest now, decrypt later (HNDL), in cui un attaccante registra oggi il traffico cifrato per decifrarlo anni dopo. Il traffico registrato è protetto unicamente dallo scambio di chiavi: per questo lo scambio di chiavi migra per primo, mentre firme e certificati possono seguire in un secondo momento.
Sulla rete, l'ibridazione è semplicemente un named group. L'IANA ha registrato X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED) per TLS 1.3 (parametri TLS IANA), e la RFC 10024 (agosto 2026) specifica i meccanismi ibridi di accordo di chiave post-quantistici e tradizionali per TLS 1.3 (rfc-editor.org). Le versioni attuali di Chrome, Edge e Firefox offrono X25519MLKEM768 per impostazione predefinita, quindi attivarlo lato server è di norma invisibile per gli utenti. Per SSH, OpenSSH ha introdotto mlkem768x25519-sha256 nella versione 9.9 (19 settembre 2024) e lo ha reso l'accordo di chiave predefinito nella 10.0 (9 aprile 2025), mentre la 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiave non post-quantistico (note di rilascio di OpenSSH).
Dove l'ibridazione è obbligatoria e dove è un consiglio
Il requisito dell'ANSSI è vincolante nel perimetro che l'agenzia amministra, come descritto nelle sue FAQ sulla crittografia post-quantistica (cyber.gouv.fr):
- Qualifica dei prodotti: i prodotti di sicurezza che dispongono di una qualifica ANSSI o che la richiedono.
- Diffusion Restreinte (DR): i sistemi informativi francesi di livello riservato e i prodotti che li proteggono.
- SAIV e SIIV: i settori di importanza vitale e i relativi sistemi informativi di importanza vitale.
Ovunque altrove, la posizione è una raccomandazione. Un'azienda francese che non vende prodotti qualificati, non tratta informazioni Diffusion Restreinte e non è un operatore di importanza vitale non è oggi vincolata dalla dottrina post-quantistica dell'ANSSI, ed è la stessa ANSSI a dichiararlo. Questa precisazione è importante quando si redige una roadmap: non presentate al vostro consiglio di amministrazione le indicazioni dell'ANSSI come una scadenza legale quando non lo sono. Potreste comunque essere vincolati da altri testi che non dicono nulla sul calcolo quantistico ma molto sul cambio di algoritmi: DORA, all'articolo 6 del Regolamento delegato (UE) 2024/1774 della Commissione, richiede una politica di cifratura e di controlli crittografici che preveda disposizioni per l'aggiornamento o la modifica della tecnologia crittografica in base agli sviluppi della crittoanalisi (EUR-Lex), e la NIS2, all'articolo 21(2)(h), richiede politiche e procedure relative all'uso della crittografia (EUR-Lex). La nostra lettura, che indichiamo come interpretazione e non come requisito di nessuno dei due testi, è che un piano di scambio di chiavi ibrido sia un modo credibile per dimostrare che tale politica è viva e non puramente decorativa. Questo articolo fornisce informazioni sulle indicazioni pubblicate e non costituisce consulenza legale.
Le date indicate dall'ANSSI
Due segnali orientano gli acquisti in Francia. L'ANSSI intende richiedere la crittografia post-quantistica per i prodotti che entrano in qualifica a partire dal 2027 e ritiene che dopo il 2030 non sarà più ragionevole acquistare prodotti privi di crittografia post-quantistica. Il secondo segnale è una raccomandazione, non un divieto, ma è un'indicazione forte per qualsiasi contratto pluriennale firmato oggi. Lo storico completo e datato è disponibile nella nostra pagina sulla dottrina ANSSI.
| Elemento | Posizione dell'ANSSI | Natura giuridica |
|---|---|---|
| Scambio di chiavi ibrido nel perimetro regolato | Richiesto già oggi (qualifica, DR, SAIV e SIIV) | Obbligo all'interno di tale perimetro |
| Crittografia post-quantistica per i prodotti che entrano in qualifica | Obiettivo a partire dal 2027 | Obiettivo dichiarato dell'agenzia |
| Acquisto di prodotti senza supporto post-quantistico dopo il 2030 | Ritenuto non ragionevole | Raccomandazione |
| Scelta dei set di parametri | Preferire i livelli di sicurezza più elevati quando i vincoli lo consentono | Raccomandazione |
Queste date sono vicine al calendario europeo: la EU Coordinated Implementation Roadmap v1.1, pubblicata il 23 giugno 2025, prevede un inventario crittografico e roadmap nazionali entro la fine del 2026, la migrazione dei casi d'uso ad alto rischio entro la fine del 2030 e di quelli a rischio medio entro la fine del 2035 (Commissione europea). Questa roadmap è un orientamento coordinato rivolto agli Stati membri, non un regolamento vincolante per le aziende, e la nostra pagina sulla roadmap riporta le tappe con il relativo stato. La TR-02102-1 del BSI tedesco, una linea guida tecnica, va nella stessa direzione: la versione 2026-01 raccomanda l'accordo di chiave post-quantistico ibrido e raccomanda l'accordo di chiave esclusivamente classico solo fino alla fine del 2031, o fino alla fine del 2030 per esigenze di protezione molto elevate.
Livelli di sicurezza più elevati quando possibile
ML-KEM prevede tre set di parametri: ML-KEM-512, ML-KEM-768 e ML-KEM-1024. L'ANSSI esprime una preferenza per i livelli di sicurezza più elevati quando prestazioni e interoperabilità lo consentono. In pratica, per i servizi web pubblici, ciò significa X25519MLKEM768 come base interoperabile, perché i browser lo offrono già oggi, riservando SecP384r1MLKEM1024 ai collegamenti in cui entrambe le estremità sono sotto il vostro controllo e i byte aggiuntivi dell'handshake sono accettabili. L'NSA segue una direzione analoga in un regime diverso: CNSA 2.0, che si applica soltanto ai National Security Systems statunitensi, specifica ML-KEM-1024, ML-DSA-87 e AES-256.
Due avvertenze. Aumentare il set di parametri non è mai un motivo per abbandonare la componente classica: un gruppo ML-KEM puro come MLKEM768 non soddisfa alcun requisito di ibridazione. Inoltre, i gruppi Kyber pre-standard, in particolare X25519Kyber768Draft00 (codepoint 0x6399), sono obsoleti e devono essere sostituiti dai gruppi ML-KEM anziché mantenuti come fallback.
Cosa distribuire e come verificarlo
Verificate cosa negoziate oggi
Iniziate in sola lettura. I gruppi ML-KEM in OpenSSL richiedono OpenSSL 3.5 o versione successiva: verificate quindi prima la versione, poi interrogate un server per un gruppo specifico.
openssl version
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>/dev/null \
| grep -i 'Negotiated TLS1.3 group'
ssh -Q kex | grep mlkem
Se la riga del gruppo risulta vuota o ripiega su X25519, il server non ha alcun gruppo ibrido abilitato. Lato server, mantenete il gruppo ibrido in prima posizione e un gruppo classico dopo di esso, così che un client datato possa ancora connettersi, e testate in staging prima della produzione. Su nginx compilato con OpenSSL 3.5 o versione successiva la direttiva è:
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
La sintassi varia tra server web e tra versioni: seguite quindi i dettagli specifici per ciascun server nella nostra guida per abilitare ML-KEM su nginx, Apache, HAProxy e Caddy invece di copiare una sola direttiva ovunque.
Evidenze da conservare
Che le regole dell'ANSSI vi vincolino o meno, la documentazione che un auditor o un cliente del settore pubblico vi chiederà è la stessa:
| Domanda che vi verrà posta | Evidenza da produrre |
|---|---|
| Dove si trova la crittografia vulnerabile ai computer quantistici nei vostri sistemi | Inventario crittografico, per servizio e per protocollo, con i relativi responsabili |
| Cosa negoziano i vostri endpoint pubblici | Risultati di scansione datati per dominio, con il gruppo negoziato registrato |
| Come cambierete algoritmo quando le indicazioni evolveranno | Politica di cifratura con un evento scatenante definito, un responsabile e un piano di rollback |
| Cosa avete richiesto ai fornitori | Clausola contrattuale che richiede lo scambio di chiavi ibrido, con la data di consegna |
Per la seconda riga, registrate il nome del gruppo e non un semplice esito positivo o negativo: un X25519MLKEM768 negoziato è un fatto che un auditor può verificare nuovamente.
Prossimo passo: misurare prima di pianificare
La dottrina dell'ANSSI si legge in un pomeriggio. Sapere quali dei vostri servizi offrono già un gruppo ibrido richiede invece una misurazione. Potete scansionare il vostro dominio con PQC Status gratuitamente per vedere le versioni TLS, le cipher suite, la catena di certificati e se viene negoziato un gruppo ML-KEM ibrido. Una scansione descrive soltanto la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità. Utilizzatela come prima riga dell'inventario, poi abilitate X25519MLKEM768 sui vostri endpoint pubblici con un fallback classico e aggiungete un requisito di scambio di chiavi ibrido al prossimo contratto che rinnoverete, in vista del segnale sugli acquisti successivo al 2030.