Il rischio “harvest now, decrypt later” è concreto: traffico cifrato oggi può essere registrato e, domani, decifrato se un avversario disporrà di capacità quantistiche adeguate. Per ridurre questa finestra di vulnerabilità sono nati gli standard post-quantum, pensati per essere deployabili già adesso. I nomi da conoscere sono ML-KEM per lo scambio chiavi, ML-DSA per le firme digitali e SLH-DSA come opzione più conservativa basata su sole funzioni hash, con FN-DSA in arrivo per chi cerca firme e chiavi più compatte. L’idea non è aspettare il “giorno X”, ma cominciare un’adozione graduale che protegga i dati a lunga vita senza rompere la compatibilità esistente.
Cosa fanno ML-KEM, ML-DSA e quando ha senso SLH-DSA
ML-KEM è un KEM a reticoli che sostituisce, in prospettiva, ECDH e DH negli handshake di protocolli come TLS, IKEv2 o QUIC. Serve a negoziare un segreto condiviso su canali pubblici e propone livelli diversi per bilanciare sicurezza e prestazioni. ML-DSA è una famiglia di firme, anch’essa a reticoli, pensata per rimpiazzare RSA ed ECDSA in certificati, code-signing e autenticazione di server e client. SLH-DSA segue una strada ancora più prudente perché si fonda solo su funzioni hash; è meno efficiente, ma molto adatta ad artefatti con orizzonte decennale come firmware e archivi legali, dove conta più la robustezza teorica della leggerezza operativa. FN-DSA, derivata da Falcon, completa il quadro per scenari in cui dimensioni ridotte delle firme sono determinanti.
Da dove partire senza strappi: usare l’ibrido oggi e migrare domani
La via pratica è attivare suite ibride nei punti critici. In TLS 1.3, ad esempio, si può combinare una curva classica come X25519 con ML-KEM-768, così se almeno uno degli schemi resta sicuro la sessione sopravvive e, allo stesso tempo, i client non aggiornati continuano a funzionare con il solo componente classico. Lo stesso approccio vale per le VPN aziendali e per la posta firmata e cifrata: per la confidenzialità si impiega un KEM post-quantum nello scambio di chiavi, mentre per l’autenticità dei certificati e dei contenuti si impiegano firme ML-DSA. Questo percorso permette un onboarding progressivo, con telemetria e rollback, evitando tagli netti che rischiano di interrompere servizi o bloccare utenti legacy.
Impatti reali su prestazioni, PKI e dispositivi
Gli handshake ibridi pesano qualche kilobyte in più e inseriscono un po’ di CPU in fase di negoziazione: conviene verificare MTU e frammentazione su link sensibili e misurare la latenza lato CDN e API. Le firme ML-DSA aumentano le dimensioni di chiavi, certificati e artefatti firmati rispetto a ECC, quindi infrastrutture come PKI, OCSP/CRL e log di trasparenza devono essere dimensionate per gestire catene più corpose senza time-out. Anche HSM, secure enclave e pipeline di firma del codice vanno aggiornati: la densità di operazioni richiesta da CI/CD, repository e distribuzioni massive impone benchmark con carichi realistici prima del rollout. Sul fronte endpoint e IoT, dove memoria e storage sono risorse limitate, SLH-DSA può risultare voluminoso; qui l’arrivo operativo di FN-DSA potrà offrire un compromesso migliore tra sicurezza e footprint.
Una roadmap senza punti rottura
Il percorso più efficace inizia da un inventario chiaro di dove si usano RSA ed ECC, con priorità ai flussi che trasportano dati destinati a vivere dieci anni o più. Si passa quindi a piloti di TLS 1.3 ibrido sui front-end più esposti, monitorando tassi di successo, tempi di handshake e percentuali di fallback. In parallelo si aggiornano le PKI emettendo nuove intermedie con ML-DSA e si sperimentano firme hash-based su firmware e documenti a lunga conservazione. Posta e VPN beneficiano di profili ibridi in S/MIME e IKEv2/QUIC che non spezzano i client esistenti, mentre le policy di sicurezza vengono rese crypto-agili per accogliere l’evoluzione degli standard senza progetti monolitici. Quando i numeri confermano stabilità e compatibilità, si estende gradualmente la copertura, iniziando dai servizi che gestiscono credenziali, pagamenti e proprietà intellettuale.
Buone pratiche per un’adozione serena
Conviene offrire per default le suite ibride e negoziare meccanicamente il meglio che client e server condividono, mantenendo osservabilità fine su errori, rinegoziazioni e dimensioni dei record. Le risorse per le terminazioni TLS e per i servizi di firma vanno scalate con criteri nuovi, perché i profili CPU e memoria degli algoritmi PQC differiscono dai vecchi. La gestione delle chiavi deve separare con chiarezza materiale classico e post-quantum, definire rotazioni e retention e prevedere un piano d’emergenza documentato. La formazione del team è l’altro pilastro: runbook per incidenti crittografici, procedure di rollback e test ripetibili evitano decisioni improvvisate nei momenti di pressione.
Gli algoritmi post-quantum non sono teoria da laboratorio: ML-KEM protegge lo scambio chiavi, ML-DSA e SLH-DSA coprono le firme già oggi, mentre FN-DSA porta opzioni più compatte all’orizzonte. L’adozione ibrida permette di iniziare subito, proteggere i dati a lunga durata e misurare l’impatto senza rompere la compatibilità. Il momento giusto è adesso, con un approccio graduale e misurato che parte dall’inventario, passa dai piloti e arriva al rollout con policy crypto-agili pronte ad aggiornarsi insieme agli standard.
Lascia un commento