Che cos'è la Post-Quantum Cryptography (PQC)?

ML-KEM (FIPS 203, ex CRYSTALS-Kyber) — un key-encapsulation mechanism. Usato per stabilire in modo sicuro una chiave simmetrica condivisa tra due parti — il ruolo che RSA-OAEP classico ed ECDH giocano oggi. Tre parameter set (ML-KEM-512, -768, -1024) a forze di sicurezza crescenti. ML-KEM-768 è il default pratico per nuovi deployment.

ML-DSA (FIPS 204, ex CRYSTALS-Dilithium) — uno schema di firma digitale. Usato per firmare documenti, certificati TLS, update software, codice, ovunque le firme RSA ed ECDSA classiche sono usate oggi. Tre parameter set (ML-DSA-44, -65, -87). ML-DSA-65 è il default pratico.

SLH-DSA (FIPS 205, ex SPHINCS+) — uno schema di firma hash-based stateless. Più lento di ML-DSA e con firme più grandi, ma la sua sicurezza dipende solo da funzioni hash — rendendolo un backup conservativo se un futuro break crittoanalitico contro gli schemi lattice-based (ML-KEM, ML-DSA) venisse trovato. Raccomandato per signing high-assurance dove la dimensione di firma è accettabile (signing root-CA, trust anchor code-signing).

Un quarto algoritmo, HQC, è stato selezionato da NIST in marzo 2025 come KEM di backup basato su assunzioni matematiche diverse da ML-KEM. Il tooling di produzione è ancora in fase emergente; ML-KEM resta il default per i deployment 2026.

Per la crittografia simmetrica (AES, SHA-2/3), l'impatto è minore: raddoppiare la key size (AES-256 su AES-128, SHA-384 su SHA-256) è generalmente sufficiente contro attacchi quantum. La migrazione simmetrica è quindi in gran parte un cambio di configurazione; la migrazione asimmetrica è la parte difficile.

Un quantum computer crittograficamente rilevante non esiste oggi. Il consenso pubblicato nella guidance regulator-level (CISA Quantum-Readiness Roadmap, NIST IR 8547, Migration Handbook BSI) tratta un CRQC capace di rompere RSA-2048 come orizzonte 5-15 anni, con incertezza significativa.

La ragione operativa per cui la migrazione parte comunque ora è il modello harvest-now-decrypt-later. Un avversario con capacità di raccogliere traffico cifrato oggi (Stati nazionali, gruppi criminali ben finanziati) può conservarlo indefinitamente. Quando un CRQC sarà disponibile, il traffico conservato è decifrato retroattivamente. Qualsiasi dato con vita utile di confidenzialità che si estende oltre la data di arrivo del CRQC è quindi *già* a rischio.

Per la maggior parte degli operatori, questo cambia le priorità:

• Alta urgenza: segreti long-lived, proprietà intellettuale, cartelle cliniche, comunicazioni classificate, chiavi document-signing, root CA.
• Media urgenza: transazioni finanziarie visibili dopo settlement, comunicazioni interne con retention pluriennale.
• Bassa urgenza: dati di sessione short-lived, traffico e-commerce transitorio.

Per gli operatori critici (difesa, governo, banking, sanità), l'assunzione operativa sicura è che tutti gli scambi cifrati *non ancora protetti da PQC* siano raccolti da almeno un avversario capace oggi. La domanda di migrazione non è quindi "quando" ma "in che ordine".

Il pattern di migrazione dominante lungo il 2024-2026 è hybrid — algoritmi classici e PQC negoziati in parallelo, con la sessione protetta solo se entrambi sono rotti. Gestisce due rischi pratici: un futuro break crittoanalitico contro ML-KEM (gli algoritmi sono nuovi, la peer review è ancora attiva) e l'interoperabilità con peer legacy che non supportano ancora PQC.

Key exchange ibrido TLS 1.3 — il pattern standardizzato IETF è X25519MLKEM768 (combinando la curva classica X25519 con ML-KEM-768). Chrome l'ha abilitato per default nel 2024 (annuncio PQC Chromium); Firefox ha seguito; Cloudflare ha riportato percentuali a doppia cifra del traffico TLS che lo usa entro fine 2024; Apple e Google l'hanno rollato sugli endpoint consumer lungo il 2024-2025. Entro il 2026, la maggior parte delle nuove connessioni TLS verso siti maggiori lo usa già.

Firme certificate ibride — i formati di firma composite (un certificato X.509 firmato sia da un algoritmo classico sia da uno PQC) sono ancora in late draft. Le root CA stanno muovendo verso chiavi PQC root con intermedi classici come pattern transizionale; ecosistemi di certificati hybrid completi sono proiettati per 2026-2028.

Code-signing — pilot PQC code-signing sono in corso in Apple, Microsoft e nelle distro Linux maggiori; il code-signing di produzione che usa PQC per uso developer generale è proiettato lungo il 2027.

L'implicazione pratica per gli operatori: il TLS ibrido è in gran parte "configura il tuo load balancer e TLS terminator" — possibile adesso. La firma ibrida è più dura e richiede planning di roadmap lungo il 2027-2028.

Un modello pratico usato dagli operatori con cui lavoriamo:

Step 1 — Inventario crittografico (settimane 1-8). Non puoi migrare quello che non sai di avere. Inventaria ogni posto dove la crittografia asimmetrica classica è usata:

• TLS endpoint (web, API, service mesh MTLS, mail, DNS-over-HTTPS).
• Gerarchie di certificati (root CA, CA intermedie, policy di issuance, lifetime).
• Chiavi code-signing (CI/CD, container registry, OS package signing, firmware signing).
• Chiavi document-signing (firme qualificate eIDAS, workflow di approvazione documenti interni).
• Endpoint VPN (IKEv2, OpenVPN, WireGuard — WireGuard usa Curve25519 e ha bisogno di un successore PQC).
• Schemi di encryption disco e DB che wrappano chiavi simmetriche con chiavi asimmetriche.
• Chiavi pubbliche hardcoded in firmware, app mobile, dispositivi embedded.

Step 2 — Prioritizza per vita utile di confidenzialità (settimane 6-12). Ogni sistema riceve un tag "data lifetime". Qualsiasi cosa dove i dati protetti devono restare confidenziali oltre l'orizzonte CRQC (5-15 anni da ora) è alta priorità.

Step 3 — TLS ibrido prima (mesi 3-9). Abilita key exchange ibrido sugli endpoint TLS. La maggior parte dei load balancer, TLS terminator e reverse proxy moderni supporta ora X25519MLKEM768. È la mossa iniziale a rischio più basso, costo più basso, valore più alto.

Step 4 — Chiavi di firma long-lived (mesi 6-24). Pianifica la migrazione di trust anchor code-signing, chiavi document-signing, servizi di firma qualificata eIDAS. È multi-annuale perché il trust anchor dev'essere disponibile dove avviene la verifica, e i verificatori vecchi devono continuare a funzionare.

Step 5 — Agilità crittografica (continuo). Progetta sistemi nuovi con astrazione di algoritmo così che la prossima migrazione (classico → ibrido → puro PQC → next-gen PQC) non richieda un redesign ogni volta. È qui che la maggior parte dei sistemi legacy fatica: le scelte crittografiche cotte dentro al design time non erano mai attese cambiare.

Per operatori UE, l'ETSI TR 103 619 framework di migrazione PQC, il manuale di migrazione BSI e il position paper ANSSI sono i documenti di riferimento convergenti. Le implementing measure NIS2 lungo il 2026-2027 ci si aspetta facciano dei piani di migrazione PQC un requisito documentato per le entità essenziali. I programmi che hanno iniziato inventario e TLS ibrido nel 2026 soddisferanno quel requisito; quelli che iniziano nel 2028 no.