Dalla minaccia “Harvest Now, Decrypt Later” agli standard FIPS 203/204/205. Come prepararsi alla rivoluzione quantistica con esempi e un piano di migrazione operativo.
C’è un orologio che sta scandendo un conto alla rovescia di cui pochi, nel panorama aziendale italiano, sembrano consapevoli. Non è una scadenza normativa, né tantomeno un aggiornamento software rimandato troppo a lungo. È la possibilità concreta che ogni dato crittografato oggi, dalle comunicazioni riservate ai segreti industriali, dai dati sanitari alle transazioni finanziarie, possa essere letto in chiaro nel giro di pochi anni.
- Harvest Now, Decrypt Later: la minaccia silenziosa già in corso
- Perché la crittografia non resisterà all’era quantistica
- Gli standard NIST per la crittografia post-quantistica
- La roadmap europea e il ruolo dell’ACN italiana nella transizione PQC
- Chi sta già implementando la crittografia post-quantistica
- Laboratorio pratico: crittografia post-quantistica con Python e liboqs
- Come pianificare la migrazione: il framework operativo in 4 fasi
- Best practices per la transizione alla crittografia post-quantistica
Per chi lavora nella cybersecurity, questa non è fantascienza, poiché gli avanzamenti nel quantum computing hanno subìto un’accelerazione impensabile nell’ultimo biennio. Google ha presentato Willow, il suo chip quantistico con 105 qubit e correzione d’errore esponenziale; Microsoft ha annunciato Majorana 1, basato su qubit topologici che promettono di passare da prototipi a macchine operative in anni, non decenni. E nel frattempo, ricercatori cinesi hanno dimostrato che il numero di qubit necessario per violare RSA-2048 potrebbe essere drasticamente inferiore a quanto stimato fino a ieri.
Ma il punto non è se un computer quantistico crittograficamente rilevante (CRQC) arriverà. Il punto è che la minaccia è già operativa oggi e ha un nome preciso: Harvest Now, Decrypt Later. Ed è da qui che dobbiamo partire.
Harvest Now, Decrypt Later: la minaccia silenziosa già in corso
La strategia “Harvest Now, Decrypt Later” (HNDL) è tanto semplice quanto devastante. Attori statali e gruppi APT intercettano e archiviano oggi enormi volumi di traffico crittografato (VPN, sessioni TLS, email cifrate, backup) con la piena consapevolezza che non possono ancora decifrarli. Attendono pazientemente il giorno in cui un computer quantistico sufficientemente potente renderà banale la fattorizzazione di RSA e la risoluzione del problema del logaritmo discreto su cui si basa ECDH. Quel giorno, tutto il traffico archiviato verrà decifrato retroattivamente.
Non si tratta di uno scenario ipotetico. Agenzie di intelligence di tutto il mondo hanno confermato l’esistenza di programmi sistematici di raccolta dati crittografati. L’NSA, attraverso le linee guida CNSA 2.0, ha imposto alle agenzie federali statunitensi la migrazione alla crittografia post-quantistica entro il 2030 per la protezione dei dati e il 2035 per le firme digitali.
La domanda critica che ogni CISO dovrebbe porsi non è “quando arriverà il quantum computer?“, ma “per quanto tempo i miei dati devono rimanere confidenziali?“. Se la risposta è più di 5-10 anni, e per dati sanitari, proprietà intellettuale, segreti militari o industriali la risposta è quasi sempre sì, allora il rischio HNDL è attuale e richiede un intervento immediato.
Perché la crittografia non resisterà all’era quantistica
Per comprendere la gravità della minaccia è necessario capire cosa rende vulnerabili gli algoritmi crittografici che utilizziamo quotidianamente. RSA, Diffie-Hellman ed ECDSA basano la propria sicurezza sulla difficoltà computazionale di due problemi matematici: la fattorizzazione di grandi numeri primi (RSA) e il calcolo del logaritmo discreto su curve ellittiche (ECDH/ECDSA). Su un computer classico, risolvere questi problemi per chiavi a 2048 o 256 bit richiederebbe miliardi di anni.
L’algoritmo di Shor, formulato nel 1994, ha dimostrato che un computer quantistico con un numero sufficiente di qubit logici potrebbe risolvere entrambi i problemi in tempo polinomiale, rendendo RSA e ECDSA completamente insicuri. Nel 2024, un team di ricerca ha pubblicato risultati che riducono di circa 20 volte il numero di qubit necessari per fattorizzare RSA-2048, portandolo potenzialmente sotto la soglia del milione. Ulteriori ottimizzazioni pubblicate nel 2025 hanno spinto alcune stime sotto i 100.000 qubit: un traguardo che diversi produttori di hardware quantistico prevedono di raggiungere entro il 2028-2030.
È fondamentale sottolineare un punto: AES-256 e gli algoritmi simmetrici non sono direttamente minacciati dall’algoritmo di Shor. L’algoritmo di Grover offre un vantaggio quadratico nella ricerca brute-force, ma questo significa semplicemente che AES-256 offrirebbe una sicurezza equivalente a 128 bit, ancora considerata sicura. Il problema reale è nella crittografia asimmetrica: scambio di chiavi, firme digitali e certificati TLS/SSL sono tutti a rischio.
Gli standard NIST per la crittografia post-quantistica
Dopo un processo di selezione durato otto anni e partito da 82 candidati iniziali, il NIST ha pubblicato il 13 agosto 2024 i primi tre standard federali di crittografia post-quantistica. Si tratta di un momento storico per la cybersecurity: per la prima volta, abbiamo algoritmi standardizzati progettati specificamente per resistere sia ai computer classici che a quelli quantistici. Questi standard sono già disponibili per l’implementazione e rappresentano la base su cui costruire la migrazione.
FIPS 203 — ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)
Basato su CRYSTALS-Kyber, è lo standard per lo scambio sicuro di chiavi. Utilizza la struttura matematica dei reticoli (lattice) e offre tre livelli di sicurezza: ML-KEM-512 (equivalente a AES-128), ML-KEM-768 (AES-192) e ML-KEM-1024 (AES-256). Le chiavi pubbliche sono più grandi rispetto a ECDH (circa 800-1568 byte contro 32), ma le prestazioni di incapsulamento/decapsulamento sono estremamente veloci, spesso più rapide dello stesso ECDH.
FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
Basato su CRYSTALS-Dilithium, è lo standard per le firme digitali post-quantistiche. Disponibile nei livelli ML-DSA-44 (sicurezza ~128 bit), ML-DSA-65 (~192 bit) e ML-DSA-87 (circa 256 bit). Le firme sono più grandi (2420-4627 byte) rispetto a ECDSA (64 byte), ma la velocità di verifica è eccellente.
FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
Basato su SPHINCS+, offre un approccio alternativo per le firme digitali fondato esclusivamente su funzioni hash. Le firme sono significativamente più grandi (fino a 49 KB), ma il vantaggio è che la sicurezza si basa su assunzioni matematiche minimali e ben comprese, rendendolo ideale come algoritmo di backup.
A marzo 2025, il NIST ha inoltre selezionato HQC (Hamming Quasi-Cyclic) come quinto algoritmo post-quantistico, progettato per funzionare come alternativa di backup a ML-KEM nel caso emergessero vulnerabilità nel framework basato su reticoli. È in fase di draft anche FIPS 206, basato su FN-DSA (Falcon), un ulteriore algoritmo di firma digitale particolarmente efficiente per firme compatte. La strategia del NIST è chiara: diversificare le basi matematiche per garantire resilienza anche in caso di avanzamenti crittanalitici imprevisti.
La roadmap europea e il ruolo dell’ACN italiana nella transizione PQC
L’Europa non è rimasta a guardare. Nel gennaio 2025, diciotto agenzie europee di cybersicurezza, tra cui l’ACN (Agenzia per la Cybersicurezza Nazionale) italiana, il BSI tedesco, l’ANSSI francese e l’NCSC olandese, hanno firmato una dichiarazione congiunta che definisce una roadmap chiara: entro il 2030, tutti i sistemi ad alto rischio devono implementare protezione post-quantistica ibrida; entro il 2035, la transizione completa deve essere conclusa. La raccomandazione esplicita è di adottare un approccio ibrido durante la fase di transizione, combinando algoritmi classici (come ECDH) con algoritmi PQC (come ML-KEM).
Per le aziende italiane, il contesto normativo aggiunge ulteriore pressione. La direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 e pienamente operativa da ottobre 2024, impone misure di sicurezza proporzionate al rischio, inclusa l’adozione di crittografia allo stato dell’arte. Il regolamento DORA (Digital Operational Resilience Act), che si applica al settore finanziario dal gennaio 2025, richiede esplicitamente la valutazione dei rischi legati all’evoluzione tecnologica, quantum computing incluso. L’ACN ha sottolineato l’importanza di avviare subito l’inventario crittografico e la pianificazione della migrazione.
Il messaggio dalle istituzioni è inequivocabile: la transizione alla crittografia post-quantistica non è un progetto futuro, ma un processo che deve iniziare oggi. Chi opera in settori regolamentati, come finanza, sanità, energia, pubblica amministrazione e difesa, ha l’obbligo sostanziale di dimostrare di aver intrapreso un percorso di crypto-agility. E anche per le PMI che gestiscono proprietà intellettuale o dati sensibili dei clienti, ritardare significa accumulare debito tecnico e rischio operativo.
Chi sta già implementando la crittografia post-quantistica
La transizione non è solo teoria accademica: i principali attori tecnologici mondiali stanno già implementando la crittografia post-quantistica nei propri prodotti. Google Chrome ha integrato il supporto per ML-KEM (inizialmente come X25519Kyber768, poi aggiornato a X25519MLKEM768) a partire dalla versione 131, rilasciata a fine 2024. Questo significa che milioni di utenti stanno già effettuando handshake TLS con protezione post-quantistica ibrida senza nemmeno saperlo. Apple ha introdotto il protocollo PQ3 in iMessage, mentre Signal utilizza il protocollo PQXDH per lo scambio di chiavi.
Cloudflare ha riportato che oltre il 35% del traffico TLS 1.3 che transita sulla propria rete utilizza già lo scambio di chiavi post-quantistico, con una tendenza in rapida crescita. AWS ha pubblicato un piano di migrazione PQC completo e sta integrando supporto nativo ML-KEM in KMS (Key Management Service) e nei propri SDK. Microsoft ha annunciato l’integrazione della crittografia post-quantistica in Azure, Microsoft 365 e nella suite di sviluppo .NET. Anche Kubernetes, dalla versione 1.32, supporta nativamente connessioni TLS con ML-KEM.
Questo dato è significativo per una ragione precisa: la PQC non è più una tecnologia sperimentale o in fase di ricerca. È già in produzione, integrata nei browser, nei servizi cloud e nei framework che le aziende utilizzano quotidianamente. Chi non ha ancora iniziato la pianificazione della migrazione è già in ritardo rispetto all’ecosistema globale.
Laboratorio pratico: crittografia post-quantistica con Python e liboqs
Passiamo dalla teoria alla pratica. Negli esempi che seguono utilizzeremo la libreria liboqs-python (Open Quantum Safe), il progetto open-source di riferimento per la sperimentazione con algoritmi PQC. La libreria implementa tutti gli algoritmi NIST standardizzati ed è supportata su Linux, macOS e Windows. Lo scopo di questi script non è l’uso in produzione, ma fornire una comprensione operativa dei meccanismi di ML-KEM e ML-DSA.
Script 1 — Scambio di chiavi con ML-KEM-768 (FIPS 203)
Installazione delle dipendenze
# Installa la libreria Open Quantum Safe per Python
# Prerequisito: liboqs deve essere compilata e installata sul sistema
pip install liboqs-python
Import e selezione dell’algoritmo
import oqs
# ML-KEM-768 corrisponde al livello di sicurezza 3 (equivalente AES-192)
# È il livello raccomandato dal NIST per la maggior parte degli usi aziendali
ALGORITMO_KEM = “ML-KEM-768”
Generazione della coppia di chiavi (lato server/destinatario)
# Il destinatario genera una coppia di chiavi: pubblica + privata
with oqs.KeyEncapsulation(ALGORITMO_KEM) as server:
chiave_pubblica = server.generate_keypair()
print(f”Algoritmo: {ALGORITMO_KEM}”)
print(f”Lunghezza chiave pubblica: {len(chiave_pubblica)} byte”)
# Output atteso: 1184 byte per ML-KEM-768
Incapsulamento (lato client/mittente)
# Il mittente usa la chiave pubblica del destinatario
# per generare un segreto condiviso + un ciphertext
with oqs.KeyEncapsulation(ALGORITMO_KEM) as client:
ciphertext, segreto_client = client.encap_secret(chiave_pubblica)
print(f”Lunghezza ciphertext: {len(ciphertext)} byte”)
print(f”Lunghezza segreto condiviso: {len(segreto_client)} byte”)
# Il segreto condiviso è 32 byte (256 bit)
# Viene usato come chiave AES per cifrare i dati veri e propri
Decapsulamento (lato server/destinatario)
# Il destinatario decapsula usando la propria chiave privata
segreto_server = server.decap_secret(ciphertext)
# Verifica: i due segreti devono essere identici
assert segreto_client == segreto_server, “ERRORE: i segreti non corrispondono!”
print(“\n✓ Scambio di chiavi ML-KEM-768 completato con successo”)
print(f”Segreto condiviso (hex): {segreto_server.hex()[:32]}…”)
Script 2 — Firma digitale con ML-DSA-65 (FIPS 204)
Configurazione dell’algoritmo di firma
import oqs
# ML-DSA-65 offre sicurezza ~192 bit (livello 3 NIST)
# Ideale per certificati digitali, firmware signing, documenti legali
ALGORITMO_SIG = “ML-DSA-65”
Generazione delle chiavi e firma del messaggio
messaggio = b”Documento riservato: report VAPT cliente Alfa Q1-2026″
with oqs.Signature(ALGORITMO_SIG) as firmatario:
# Genera la coppia di chiavi per la firma
chiave_pubblica_sig = firmatario.generate_keypair()
print(f”Algoritmo: {ALGORITMO_SIG}”)
print(f”Lunghezza chiave pubblica: {len(chiave_pubblica_sig)} byte”)
# Firma il messaggio con la chiave privata
firma = firmatario.sign(messaggio)
print(f”Lunghezza firma: {len(firma)} byte”)
# Output atteso: ~3309 byte (molto più grande di ECDSA: 64 byte)
Verifica della firma (lato destinatario)
# Il verificatore usa solo la chiave pubblica
with oqs.Signature(ALGORITMO_SIG) as verificatore:
is_valida = verificatore.verify(
messaggio, firma, chiave_pubblica_sig
)
print(f”\n✓ Firma valida: {is_valida}”)
Test di integrità: tentativo di manomissione
# Simuliamo un attaccante che modifica il messaggio
messaggio_alterato = b”Documento riservato: report VAPT cliente Beta Q1-2026″
try:
verificatore.verify(
messaggio_alterato, firma, chiave_pubblica_sig
)
print(“✗ ATTENZIONE: firma accettata su messaggio alterato!”)
except Exception:
print(“✓ Firma correttamente rifiutata sul messaggio alterato”)
Script 3 — Confronto prestazionale: RSA vs ML-KEM vs ML-DSA
Setup del benchmark
import oqs
import time
def benchmark(nome, funzione, iterazioni=100):
“””Misura il tempo medio di esecuzione in millisecondi”””
inizio = time.perf_counter()
for _ in range(iterazioni):
funzione()
durata = (time.perf_counter() – inizio) / iterazioni * 1000
print(f” {nome}: {durata:.3f} ms (media su {iterazioni} iterazioni)”)
Benchmark ML-KEM: generazione chiavi, incapsulamento, decapsulamento
print(“\n=== Benchmark ML-KEM-768 (Key Encapsulation) ===”)
with oqs.KeyEncapsulation(“ML-KEM-768”) as kem:
pk = kem.generate_keypair()
# Misura le operazioni critiche
benchmark(“Generazione chiavi”, lambda: kem.generate_keypair())
with oqs.KeyEncapsulation(“ML-KEM-768”) as kem2:
benchmark(“Incapsulamento”, lambda: kem2.encap_secret(pk))
ct, _ = oqs.KeyEncapsulation(“ML-KEM-768”).encap_secret(pk)
benchmark(“Decapsulamento”, lambda: kem.decap_secret(ct))
Benchmark ML-DSA: firma e verifica
print(“\n=== Benchmark ML-DSA-65 (Digital Signature) ===”)
msg = b”Benchmark test message for post-quantum signatures”
with oqs.Signature(“ML-DSA-65”) as sig:
pk_sig = sig.generate_keypair()
firma_test = sig.sign(msg)
benchmark(“Generazione chiavi”, lambda: sig.generate_keypair())
benchmark(“Firma”, lambda: sig.sign(msg))
with oqs.Signature(“ML-DSA-65”) as ver:
benchmark(“Verifica”, lambda: ver.verify(msg, firma_test, pk_sig))
Output atteso (valori indicativi su CPU moderna)
# === Benchmark ML-KEM-768 (Key Encapsulation) ===
# Generazione chiavi: 0.045 ms
# Incapsulamento: 0.058 ms
# Decapsulamento: 0.063 ms
#
# === Benchmark ML-DSA-65 (Digital Signature) ===
# Generazione chiavi: 0.120 ms
# Firma: 0.350 ms
# Verifica: 0.130 ms
#
# NOTA: ML-KEM è spesso più veloce di ECDH tradizionale!
# Il trade-off è nelle dimensioni maggiori di chiavi e ciphertext.
Come pianificare la migrazione: il framework operativo in 4 fasi
La migrazione alla crittografia post-quantistica è un’operazione un processo graduale che richiede pianificazione accurata. Il primo passo, e il più sottovalutato, è l’inventario crittografico: un censimento completo di tutti i punti in cui l’organizzazione utilizza crittografia asimmetrica. Questo include certificati TLS/SSL, VPN (IPsec e WireGuard), firme digitali, chiavi SSH, token JWT, cifratura di database e backup, protocolli IoT e connessioni API. Senza questo inventario, qualsiasi piano di migrazione è cieco.
La seconda fase è la classificazione del rischio basata sulla shelf life dei dati protetti. Dati che devono rimanere confidenziali per oltre 10 anni (proprietà intellettuale, dati sanitari, segreti di stato) hanno priorità massima. La terza fase è l’implementazione dell’approccio ibrido: affiancare agli algoritmi classici (RSA, ECDH) gli algoritmi PQC (ML-KEM, ML-DSA) in modalità combinata, così che la sicurezza sia garantita anche nel caso in cui uno dei due sistemi risulti compromesso. Questo è l’approccio raccomandato da NIST, BSI, ANSSI e ACN.
La quarta fase è la crypto-agility: progettare i sistemi in modo che gli algoritmi crittografici possano essere sostituiti senza ristrutturare l’intera architettura. In concreto, questo significa adottare librerie crittografiche modulari, evitare l’hard coding degli identificatori degli algoritmi e implementare meccanismi di negoziazione flessibili (come il TLS cipher suite negotiation). L’agilità crittografica non è un lusso, ma l’assicurazione che protegge l’investimento nella migrazione PQC.
Best practices per la transizione alla crittografia post-quantistica
Di seguito le azioni concrete che ogni organizzazione dovrebbe intraprendere per avviare e governare la transizione alla crittografia quantum-safe, ordinate per priorità di implementazione.
- Eseguire un inventario crittografico completo. Senza una mappa chiara di dove e come la crittografia asimmetrica è utilizzata (certificati, VPN, SSH, JWT, API), è impossibile pianificare una migrazione efficace. Strumenti come IBM Quantum Safe Explorer o script personalizzati possono automatizzare la discovery.
- Classificare i dati in base alla shelf life di confidenzialità. I dati che devono restare riservati per oltre 10 anni (proprietà intellettuale, segreti industriali, dati sanitari) sono esposti al rischio HNDL oggi e richiedono protezione PQC prioritaria.
- Adottare immediatamente l’approccio ibrido (classico + PQC). La combinazione di ECDH + ML-KEM (es. X25519MLKEM768 nel TLS 1.3) garantisce protezione sia contro attacchi classici sia quantistici, minimizzando il rischio in caso di vulnerabilità scoperte in uno dei due schemi. È l’approccio ufficialmente raccomandato da NIST, BSI e ACN.
- Progettare per la crypto-agility fin da subito. Evitare di hard-codare identificatori di algoritmi, adottare librerie modulari (come liboqs, BoringSSL, AWS-LC), e implementare configurazioni esternalizzate per cipher suite e parametri crittografici. Se un algoritmo PQC dovesse rivelarsi vulnerabile, la sostituzione deve essere rapida e non traumatica.
- Aggiornare la catena dei certificati TLS/SSL. Evitare di hard-codare identificatori di algoritmi, adottare librerie modulari (come liboqs, BoringSSL, AWS-LC), e implementare configurazioni esternalizzate per cipher suite e parametri crittografici. Se un algoritmo PQC dovesse rivelarsi vulnerabile, la sostituzione deve essere rapida e non traumatica.
- Aggiornare la catena dei certificati TLS/SSL. Verificare che la propria CA supporti certificati ibridi o PQC. DigiCert e altre CA globali stanno già rilasciando certificati con firma ML-DSA. Pianificare il rinnovo dei certificati con algoritmi post-quantistici durante i cicli naturali di scadenza.
- Testare l’impatto sulle prestazioni di rete. Le chiavi e le firme PQC sono significativamente più grandi (ML-KEM-768: 1184 byte per la chiave pubblica vs 32 di X25519). Eseguire test di carico sugli handshake TLS ibridi per verificare che l’infrastruttura di rete (firewall, WAF, bilanciatori) gestisca correttamente i pacchetti più grandi senza frammentazione o timeout.
- Includere la PQC nei framework di risk assessment (NIS2, DORA, ISO 27001). Le normative europee richiedono già l’adozione di crittografia allo stato dell’arte proporzionata al rischio. Documentare la roadmap PQC nel registro dei rischi e nei piani di trattamento dimostra due diligence e prepara l’organizzazione alle verifiche di conformità.
- Formare il team IT e i decision-maker sulla minaccia quantistica. La transizione PQC è sia tecnica che organizzativa. I team di sicurezza devono comprendere i nuovi algoritmi, i team infrastrutturali devono gestire l’impatto su reti e certificati, e il management deve allocare budget e tempi adeguati. Senza consapevolezza a tutti i livelli, la migrazione si arena.
- Monitorare gli aggiornamenti NIST e le advisory ACN/ENISA. La PQC è un campo in evoluzione: FIPS 206 (FN-DSA) e lo standard HQC sono in fase di finalizzazione. Nuove vulnerabilità o ottimizzazioni possono modificare le raccomandazioni. Iscriversi alla mailing list NIST PQC Forum e alle comunicazioni ACN garantisce aggiornamenti tempestivi.
Conclusione: il momento di agire è adesso
La crittografia post-quantistica non è una tecnologia del futuro: è una necessità del presente. Mentre scriviamo, dati sensibili vengono intercettati e archiviati in attesa di essere decifrati da computer quantistici che si avvicinano sempre più rapidamente alla soglia di rilevanza crittografica. Gli standard NIST sono pubblicati e disponibili, i principali vendor tecnologici stanno già integrando il supporto PQC nei propri prodotti, mentre le istituzioni europee hanno tracciato una roadmap con scadenze precise.
Per le aziende italiane, la finestra per una transizione ordinata e pianificata si sta restringendo. Chi inizia oggi l’inventario crittografico e l’adozione dell’approccio ibrido avrà il vantaggio di una migrazione graduale, gestibile e conforme. Chi aspetta si troverà a gestire una transizione d’emergenza, più costosa, più rischiosa e potenzialmente imposta dalle circostanze o dalla normativa.
Vuoi valutare la tua organizzazione al rischio quantistico? Contatta il team Cyberment per un assessment crittografico dedicato.
- Autore articolo
- Gli ultimi articoli
