Crittografia post-quantistica

Un computer quantistico calcola con i qubit, che possono contenere contemporaneamente una combinazione di 0 e 1 ed essere collegati in modo che i loro stati dipendano l'uno dall'altro. Per la maggior parte dei compiti non è più veloce di un computer normale. Per alcuni problemi con la giusta struttura matematica, un algoritmo quantistico fa sì che le risposte sbagliate si annullino e quella giusta emerga, e questo dà un'accelerazione enorme. Le macchine di oggi hanno troppo pochi qubit e troppi errori per minacciare la crittografia. Per romperla servirebbe una macchina grande e tollerante ai guasti, che corregga i propri errori, e nessuno l'ha ancora costruita. Per la Sua azienda il punto pratico è circoscritto: una macchina del genere romperebbe la crittografia a chiave pubblica che protegge quasi ogni Sua connessione, quindi la sostituzione va pianificata prima che esista.

Perché un computer quantistico grande e tollerante ai guasti, con l'algoritmo di Shor, potrebbe rompere i metodi a chiave pubblica usati oggi per concordare chiavi e firmare dati: RSA e la crittografia a curve ellittiche (ECC). Questi due proteggono lo scambio di chiavi di quasi ogni connessione HTTPS, VPN e SSH e le firme su certificati, aggiornamenti software e documenti. Un attaccante con una macchina del genere potrebbe leggere traffico registrato in precedenza e falsificare firme. La crittografia simmetrica come AES, che cifra i dati una volta concordata la chiave, viene indebolita solo in modo moderato dall'algoritmo di Grover e resta utilizzabile con chiavi da 256 bit. Oggi un computer simile non esiste e nessuno sa dire in che anno esisterà. Il rischio è reale per i dati che devono restare segreti per molti anni: va pianificato, non è un'emergenza. La soluzione è software, non hardware: nuovi algoritmi standardizzati dal NIST nel 2024 e distribuiti con gli aggiornamenti.

Trasforma in facili i problemi difficili su cui si basano. RSA è sicuro perché nessuno riesce a scomporre un numero molto grande nei suoi due fattori primi in tempi ragionevoli; la crittografia a curve ellittiche è sicura perché nessuno riesce a ricavare il numero segreto dietro un punto pubblico della curva. Peter Shor dimostrò nel 1994 che un computer quantistico può trovare in entrambi i problemi uno schema ripetuto nascosto, un periodo, da cui il segreto si ricava rapidamente. Su una macchina abbastanza grande l'attacco richiede un tempo praticabile invece che impossibile. Chiavi più lunghe non salvano RSA né ECC: rendono l'attacco quantistico solo un po' più lento. Per questo la risposta è nuova matematica, come i problemi sui reticoli alla base di ML-KEM e ML-DSA, per i quali non si conosce alcun algoritmo quantistico efficiente. Le stime pubblicate della macchina necessaria sono ancora molto lontane da tutto ciò che è stato costruito.

Molto meno di quanto l'algoritmo di Shor significhi per RSA: indebolisce la crittografia simmetrica e le funzioni di hash, ma non le rompe. Lov Grover dimostrò nel 1996 che un computer quantistico può esplorare le possibilità in circa la radice quadrata del numero di passi abituale. Applicato all'indovinare una chiave, dimezza grosso modo la lunghezza della chiave in bit: in teoria una chiave AES a 128 bit si comporta più come una da 64. In pratica l'attacco è una catena di passi lunghissima che non si può dividere utilmente su molte macchine, quindi anche AES-128 resta tutt'altro che facile da rompere. Il consiglio comune è semplice: AES-256 per i dati che devono restare segreti a lungo e SHA-256 o superiore per l'hashing. La maggior parte dei sistemi moderni supporta già entrambi, quindi questa parte del cambiamento è di solito una scelta di configurazione, non un progetto di migrazione. Il lavoro vero riguarda i metodi a chiave pubblica.

Nessuno lo sa, e chi indica un anno sta tirando a indovinare. Una macchina abbastanza grande e stabile da eseguire l'algoritmo di Shor contro le lunghezze di chiave di oggi richiede progressi nella qualità dei qubit, nella correzione degli errori e nella scala che non sono ancora stati dimostrati. Sondaggi tra esperti e roadmap dei produttori danno intervalli, non date, e gli intervalli si spostano. La Sua pianificazione però non dipende da quella data. I regolatori hanno fissato le proprie scadenze: la roadmap coordinata dell'UE del 23 giugno 2025 chiede di migrare i casi d'uso ad alto rischio entro la fine del 2030, e le linee guida per la transizione del NIST (NIST IR 8547, bozza di novembre 2024, versione definitiva di ottobre 2026) deprecano dopo il 2030 i metodi a chiave pubblica vulnerabili ai computer quantistici, come RSA e la crittografia a curve ellittiche, e li vietano negli standard del NIST dopo il 2035. Clienti, revisori e gare chiederanno di queste date molto prima che esista un computer quantistico. Per i dati che devono restare segreti per un decennio o più, la disuguaglianza di Mosca mostra perché aspettare quella data è la strategia sbagliata.

La crittografia post-quantistica (PQC) è crittografia a chiave pubblica progettata per restare sicura contro un grande computer quantistico, pur funzionando su computer normali. Il NIST ha pubblicato i primi standard il 13 agosto 2024: FIPS 203 (ML-KEM) per stabilire le chiavi e FIPS 204 (ML-DSA) e FIPS 205 (SLH-DSA) per le firme digitali. Si basano su problemi matematici, come trovare vettori corti in reticoli ad alta dimensione, o sulla sicurezza delle funzioni di hash, per i quali non si conosce alcun attacco quantistico efficiente. Migrare significa aggiornare software, librerie, protocolli e certificati, non acquistare hardware quantistico. Non è nemmeno la stessa cosa della distribuzione quantistica delle chiavi, che richiede apparati ottici speciali. Il prezzo del cambiamento è la dimensione: chiavi e firme post-quantistiche sono più grandi di quelle attuali, gli handshake crescono e alcuni apparati datati faticano. La maggior parte delle organizzazioni incontra la PQC prima con gli aggiornamenti di browser, sistemi operativi e software VPN, e poi deve occuparsi dei propri server e applicazioni.

Sono i primi tre standard post-quantistici del National Institute of Standards and Technology (NIST) statunitense, pubblicati il 13 agosto 2024 dopo una competizione aperta e internazionale iniziata nel 2016. FIPS 203 specifica ML-KEM, un meccanismo di incapsulamento delle chiavi con cui due parti concordano una chiave segreta comune; prende il ruolo che oggi hanno RSA e Diffie-Hellman su curve ellittiche nello scambio di chiavi. FIPS 204 specifica ML-DSA, lo schema principale di firma digitale. FIPS 205 specifica SLH-DSA, uno schema di firma più lento e con firme più grandi, basato solo su funzioni di hash e mantenuto come alternativa prudente. Pur essendo standard federali statunitensi, sono il riferimento in tutto il mondo: agenzie europee come la tedesca BSI e la francese ANSSI raccomandano, tra gli altri, questi algoritmi, di solito combinati con uno classico. Per Lei sono i nomi da cercare nella documentazione dei fornitori, nelle loro roadmap e nelle risposte alle gare.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) è il metodo post-quantistico per concordare una chiave segreta su una rete aperta, ed è quello che incontrerà per primo. Deriva dalla proposta CRYSTALS-Kyber. Una parte pubblica una chiave pubblica; l'altra la usa per avvolgere un segreto casuale nuovo che solo il titolare della chiave privata può aprire. Quel segreto diventa poi la chiave di una crittografia simmetrica veloce come AES. Esiste in tre dimensioni, ML-KEM-512, ML-KEM-768 e ML-KEM-1024, e 768 è la scelta comune. È veloce, spesso paragonabile alle curve ellittiche, ma chiave pubblica e testo cifrato pesano circa un kilobyte ciascuno, contro i 32 byte di X25519. Questa dimensione spiega perché alcuni firewall e apparati intermedi datati faticano con gli handshake post-quantistici. In TLS ML-KEM compare di solito combinato con X25519 nel gruppo ibrido X25519MLKEM768, che la maggior parte dei browser offre già.

Sono i due standard di firma post-quantistica: ML-DSA (FIPS 204, da CRYSTALS-Dilithium) e SLH-DSA (FIPS 205, da SPHINCS+). Una firma digitale dimostra chi ha prodotto dei dati e che nessuno li ha modificati; protegge certificati, aggiornamenti software, firmware, documenti e codice. ML-DSA è la scelta generale: veloce, con firme di alcuni kilobyte invece dei 64 byte di una tipica firma ECDSA. SLH-DSA si basa solo sulla sicurezza delle funzioni di hash, il che la rende molto prudente, al prezzo di firme più grandi e di una firma più lenta; è adatta a radici di fiducia di lunga durata e alla firma del firmware. Le firme contano meno per «harvest now, decrypt later», perché una firma falsificata aiuta un attaccante solo quando un computer quantistico esiste già. Per questo la maggior parte delle organizzazioni cambia prima lo scambio di chiavi e poi le firme. L'ecosistema dei certificati con firma post-quantistica è ancora in costruzione: chieda ai fornitori i loro piani invece di aspettarsi certificati post-quantistici già oggi.

Sono i prossimi algoritmi post-quantistici nel percorso del NIST, non ancora standard definitivi. HQC (Hamming Quasi-Cyclic) è un metodo di incapsulamento delle chiavi che il NIST ha scelto nel marzo 2025 come riserva per ML-KEM. Si basa su codici correttori d'errore anziché su reticoli, quindi se un giorno si trovasse una debolezza nei problemi sui reticoli, sarebbe pronto un algoritmo di un'altra famiglia matematica. Il NIST annunciava allora una bozza di standard circa un anno dopo e uno standard definitivo nel 2027. FN-DSA, basato sulla proposta FALCON, è uno schema di firma previsto come FIPS 206; le sue firme sono molto più piccole di quelle di ML-DSA, il che aiuta dove lo spazio è poco, ma è più difficile da implementare in modo sicuro. La lezione per la Sua pianificazione: non puntare per sempre su un solo algoritmo. Scelga prodotti che possano cambiare algoritmo tramite configurazione o aggiornamenti. Questa capacità, detta agilità crittografica, La protegge se uno standard cambia o emerge un difetto di implementazione.

Lo scambio di chiavi ibrido combina nello stesso handshake TLS un metodo classico (X25519, uno scambio su curve ellittiche) con uno post-quantistico (ML-KEM-768) e ricava la chiave di sessione da entrambi. La chiave resta segreta finché uno dei due regge: se si trovasse un difetto nel ancora giovane ML-KEM, X25519 continuerebbe a tenere fuori gli attaccanti di oggi; contro un futuro computer quantistico lo farebbe ML-KEM. Per questo la maggior parte delle linee guida, comprese quelle di agenzie europee come BSI e ANSSI, preferisce l'ibrido durante la transizione. X25519MLKEM768 è il nome di questa combinazione in TLS. I principali browser la offrono già di default e grandi reti di distribuzione dei contenuti e molti servizi cloud la accettano, quindi una parte del Suo traffico web potrebbe già usarla senza che Lei abbia cambiato nulla. Una connessione che la usa rende il traffico registrato molto più difficile da decifrare in futuro. Quelle da pianificare sono le connessioni che usano ancora solo uno scambio di chiavi classico: server datati, appliance, VPN e applicazioni interne.

Per quasi tutte le aziende, no. La distribuzione quantistica delle chiavi (QKD) usa la fisica dei singoli fotoni, inviati su fibra dedicata o in spazio libero, per concordare una chiave in modo che le intercettazioni si rivelino. Richiede hardware speciale a entrambe le estremità, funziona su distanze limitate a meno di aggiungere stazioni di rilancio fidate e non autentica da sola le due parti, quindi ha comunque bisogno di firme classiche o post-quantistiche. La crittografia post-quantistica è invece software che gira sulle reti e sui dispositivi che già possiede. Agenzie europee per la sicurezza, tra cui la tedesca BSI, la francese ANSSI e l'olandese NLNCSA, hanno pubblicato una posizione comune che considera la crittografia post-quantistica la strada principale e la QKD adatta al massimo a usi di nicchia. L'infrastruttura europea di comunicazione quantistica EuroQCI serve esigenze governative specifiche ed è cosa diversa da ciò che una media impresa dovrebbe acquistare. Se un fornitore propone la QKD come risposta a «harvest now, decrypt later» per una normale rete d'ufficio, chieda che cosa fa in più rispetto a una configurazione TLS o VPN ibrida.

Significa che un attaccante registra oggi traffico cifrato e lo conserva, per decifrarlo quando esisterà un computer quantistico abbastanza potente. Registrare costa poco ed è invisibile per Lei: può avvenire in un punto di interscambio internet, su un router compromesso o presso un provider, lontano dalla Sua rete. È a rischio solo il traffico il cui scambio di chiavi è vulnerabile ai computer quantistici, e solo i dati che conteranno ancora quando verranno decifrati. Cartelle cliniche, progetti, codice sorgente, contratti di lunga durata, fascicoli legali e dati personali conservati per molti anni sono esempi tipici; il calendario delle consegne di questa settimana no. Un modo comune per valutarlo è la disuguaglianza di Mosca: se gli anni in cui i dati devono restare segreti più gli anni della Sua migrazione superano gli anni che mancano a un computer del genere, il momento di iniziare è adesso. La risposta pratica è portare per primo a metodi post-quantistici ibridi lo scambio di chiavi che protegge i dati di lunga vita, perché è lì che le registrazioni di oggi diventerebbero le fughe di dati di domani. Le firme possono seguire più tardi.

I dati che oggi attraversano una rete e devono restare riservati anche dopo l'arrivo di un grande computer quantistico. Per ogni insieme di dati si ponga due domande: viaggia su una connessione con uno scambio di chiavi vulnerabile ai computer quantistici, e per quanti anni la sua divulgazione farebbe ancora danno? Esempi tipici di lunga durata sono cartelle dei pazienti e del personale, progetti di prodotto e codice sorgente, documenti di fusioni e contenziosi, contratti con la pubblica amministrazione, dati biometrici e credenziali mai cambiate. I dati di breve durata, come un codice monouso o i prezzi di questo mese, non meritano preoccupazione. I dati archiviati sono un'altra questione: di solito li protegge una crittografia simmetrica come AES, che un computer quantistico non rompe, a meno che le loro chiavi non siano scambiate o avvolte con RSA. Metta la lista per iscritto con un responsabile e un periodo di conservazione per voce: diventa l'ordine di priorità della migrazione e la base del calcolo di Mosca. Un sensore di rete non può classificare i Suoi dati; quella lista viene dall'azienda.

Metta tre numeri uno accanto all'altro per ogni insieme di dati o sistema importante. X è per quanti anni i dati devono restare segreti. Y è quanti anni Le serviranno per portare quel sistema alla crittografia post-quantistica, compresi fornitori, test e cicli di budget. Z è quanti anni mancano prima che un computer quantistico possa rompere la crittografia a chiave pubblica di oggi. Se X più Y è maggiore di Z, i dati inviati oggi sono già esposti a «harvest now, decrypt later». Michele Mosca ha descritto la disuguaglianza nel 2015, in un lavoro pubblicato come IACR ePrint 2015/1075. Z è sconosciuto, quindi non finga di conoscerlo: provi un valore prudente e uno rilassato e guardi quali sistemi falliscono anche con quello rilassato. Per esempio, contratti che devono restare riservati per 10 anni, su un sistema che richiede 5 anni di migrazione, falliscono per qualsiasi Z inferiore a 15 anni. Il risultato è una lista di priorità, non una previsione, e un ragionamento che un revisore o un consiglio di amministrazione possono seguire.

La minaccia no, ma buona parte del marketing che la circonda sì. I fatti sono solidi: il NIST ha pubblicato standard definitivi nell'agosto 2024, browser e grandi fornitori cloud usano già lo scambio di chiavi ibrido post-quantistico e l'UE ha una roadmap coordinata con delle date. Ciò che è incerto è quando esisterà un computer quantistico capace, ed è proprio per questo che pianificare batte aspettare: cambiare la crittografia di un'intera azienda richiede anni. La moda sta nei prodotti che promettono l'immunità dagli attacchi quantistici, nei conti alla rovescia e nella pressione ad acquistare hardware che non serve. Una posizione sobria per la maggior parte delle medie imprese: nessuna spesa d'emergenza, ma un inventario quest'anno, domande sulla PQC in ogni nuovo acquisto, aggiornamenti che attivino lo scambio ibrido dove i fornitori lo offrono e priorità ai dati che devono restare segreti a lungo. Costa poco ed evita in futuro una migrazione affrettata e costosa.

Sì, come tema di pianificazione e di rischio, non come crisi. Merita un posto all'ordine del giorno per tre motivi. È un cambiamento lungo e trasversale che per diversi anni tocca fornitori, prodotti e budget, e solo il vertice può metterlo in sequenza. Riguarda dati che l'azienda ha promesso di proteggere per molti anni, come quelli di clienti, pazienti o i progetti. E clienti, assicuratori e gare pubbliche iniziano a chiederne conto, quindi la risposta diventa una questione commerciale. Secondo la NIS2, gli organi di gestione dei soggetti interessati devono approvare le misure di gestione del rischio di cibersicurezza e sovrintenderne l'attuazione, e una politica sulla crittografia è una di queste. Al consiglio serve poco: un inventario di dove si usa crittografia vulnerabile ai computer quantistici, una lista di priorità basata su quanto a lungo i dati devono restare segreti, un responsabile designato e una tabella di marcia allineata alle tappe europee del 2030 e del 2035. Non serve una lezione tecnica sui qubit.

La raccomandazione (UE) 2024/1101 della Commissione dell'11 aprile 2024 ha chiesto agli Stati membri di coordinare la transizione, e il gruppo di cooperazione NIS ha pubblicato il 23 giugno 2025 una tabella di marcia coordinata: avviare la transizione, proteggere i casi d'uso ad alto rischio entro la fine del 2030 e migrare quanti più sistemi possibile entro il 2035. È una tabella di marcia per gli Stati membri, non una legge che vincola direttamente la Sua azienda; le autorità nazionali possono tradurla in linee guida o norme. Il suo primo passo pratico è sapere dove usa la crittografia.

Che la transizione sia iniziata ovunque. La roadmap coordinata pubblicata dal gruppo di cooperazione NIS il 23 giugno 2025, in seguito alla raccomandazione (UE) 2024/1101 della Commissione, fissa tre tappe: primi passi entro la fine del 2026, migrazione dei casi d'uso ad alto rischio entro la fine del 2030 e di quanti più sistemi possibile entro il 2035. La prima tappa riguarda la preparazione: gli Stati membri definiscono piani nazionali di transizione, le organizzazioni iniziano a inventariare dove usano crittografia vulnerabile ai computer quantistici e il rischio di ogni uso viene valutato, così che i casi ad alto rischio possano essere sperimentati presto. La roadmap si rivolge agli Stati membri e ai loro settori pubblico e critico, non direttamente alla Sua azienda, e le autorità nazionali la tradurranno in proprie linee guida. La sua logica vale comunque per ogni organizzazione: entro la fine del 2026 sappia dov'è la Sua crittografia, chi è responsabile di ogni sistema e quali devono migrare per primi. Segua ciò che pubblica la Sua autorità nazionale per la cibersicurezza.

Non esplicitamente, ma entrambi vanno in quella direzione. La NIS2, direttiva (UE) 2022/2555, richiede ai soggetti interessati politiche e procedure relative all'uso della crittografia e, se del caso, della cifratura, nell'ambito delle misure di gestione del rischio di cibersicurezza dell'articolo 21. Il Cyber Resilience Act (CRA), regolamento (UE) 2024/2847, richiede che i prodotti con elementi digitali proteggano la riservatezza dei dati con meccanismi allo stato dell'arte, tra i requisiti essenziali del suo allegato I. Nessuno dei due nomina un algoritmo. Lo stato dell'arte però si muove: quando gli standard NIST, le linee guida delle agenzie europee e la roadmap dell'UE trattano lo scambio di chiavi ibrido post-quantistico come normale, un prodotto o una politica che lo ignora diventa più difficile da difendere in un audit o in una gara. La stessa roadmap dell'UE presenta la transizione post-quantistica come un passo senza rimpianti che sostiene NIS2 e CRA. Verifichi il recepimento nazionale della NIS2 e le linee guida della Sua autorità nazionale, perché i dettagli possono variare da Paese a Paese.

Soprattutto cose ordinarie e poco costose. Primo, tenga aggiornati browser, sistemi operativi, client VPN, server e librerie: buona parte del cambiamento post-quantistico arriva con gli aggiornamenti, e i browser moderni usano già di default lo scambio di chiavi ibrido. Secondo, elenchi dove usa crittografia che controlla direttamente: il sito web e il suo hosting, l'accesso remoto, la posta, lo scambio di file con i clienti e ogni apparato con certificati propri. Terzo, segni i dati che devono restare segreti per molti anni. Quarto, aggiunga una domanda a ogni nuovo acquisto o rinnovo di contratto: il prodotto supporta lo scambio di chiavi ibrido post-quantistico, e se no, quando? Quinto, preferisca fornitori in grado di cambiare algoritmo con gli aggiornamenti. Comprare speciali prodotti quantistici non è nella lista. NetSenX può aiutare nel secondo passo: NQCI, in anteprima, è visibile in ogni piano e attivo dal piano Pro, e richiede il sensore di cattura dei pacchetti, disattivato per impostazione predefinita, attivato su un agente Linux o come sensore SPAN/TAP; la modalità di base su macOS non vede gli handshake.

Anni, per la maggior parte delle organizzazioni, ed è per questo che iniziare presto conta più della scadenza esatta. Il cambiamento tocca ogni punto in cui si concordano chiavi o si firmano dati: siti web, VPN, SSH, posta, applicazioni interne, certificati, moduli di sicurezza hardware (HSM), smart card, macchine e il loro firmware. Molto dipende da quando i fornitori rilasceranno il supporto post-quantistico e dai Suoi cicli di sostituzione: un firewall acquistato quest'anno potrebbe essere ancora in funzione nel prossimo decennio, un controllore industriale molto più a lungo. I cambiamenti passati danno la scala: dismettere SHA-1 e le vecchie versioni di TLS ha richiesto al settore molti anni dai primi avvisi allo spegnimento definitivo. Una piccola azienda che usa soprattutto servizi cloud e software aggiornato può fare buona parte del percorso con normali aggiornamenti, entro un ciclo di rinnovo ordinario. Un'azienda con software proprio, apparati di lunga durata o una propria autorità di certificazione deve aspettarsi un programma distribuito su più anni. La Y della disuguaglianza di Mosca è una Sua stima: la scriva con le sue ragioni.

Protegge il traffico di oggi dalla decifratura di domani e ottiene diversi vantaggi che non dipendono affatto dai computer quantistici. I dati di lunga durata smettono di essere esposti a «harvest now, decrypt later» non appena il loro scambio di chiavi passa a un metodo ibrido. L'inventario costruito strada facendo scopre vecchie versioni di TLS, cifrari deboli, certificati scaduti o dimenticati e server non gestiti, che sono rischi già oggi. L'agilità crittografica, la capacità di cambiare algoritmo con la configurazione, rende più economico il prossimo cambiamento imposto, qualunque ne sia la causa. Sul piano commerciale può rispondere alle gare e ai clienti con fatti e date invece che con una casella vuota, ed è pronto quando le autorità nazionali tradurranno la roadmap dell'UE in linee guida. Fatta nei normali cicli di sostituzione, la migrazione costa molto meno di una fatta sotto pressione. Ciò che non guadagna è l'immunità: la crittografia post-quantistica protegge lo scambio di chiavi e le firme, non le password rubate, il phishing o i sistemi non aggiornati.

Soprattutto compatibilità e prestazioni, raramente la matematica. Le chiavi post-quantistiche sono più grandi, quindi un ClientHello TLS con X25519MLKEM768 non sta più in un singolo pacchetto di rete; alcuni firewall, bilanciatori di carico e sistemi di prevenzione delle intrusioni datati lo gestiscono male e scartano o reimpostano la connessione. Moduli di sicurezza hardware, smart card e dispositivi embedded possono non avere memoria o firmware per i nuovi algoritmi. Firme di diversi kilobyte allungano le catene di certificati e rallentano i collegamenti limitati. Le implementazioni giovani possono contenere bug, un motivo in più per usare metodi ibridi e librerie ben mantenute. I proxy di intercettazione che decifrano TLS potrebbero non supportare i nuovi gruppi e riportare in silenzio le connessioni allo scambio di chiavi classico. Lo pianifichi: provi con traffico reale in un segmento di test, mantenga il ripiego classico durante la transizione, verifichi che gli apparati intermedi siano aggiornati e misuri poi quali connessioni usano davvero lo scambio ibrido. Una vista degli handshake in rete mostra regressioni che i file di configurazione non mostrano.

L'agilità crittografica è la capacità di cambiare gli algoritmi crittografici usati da un sistema senza riscriverlo né sostituirlo. In pratica significa che gli algoritmi si scelgono con la configurazione e non sono scritti nel codice; il software usa librerie mantenute che ricevono nuovi algoritmi con gli aggiornamenti; certificati e chiavi sono gestiti centralmente, con responsabili e scadenze noti; e Lei sa dove viene usato ogni algoritmo. Conta adesso perché la transizione post-quantistica non sarà l'ultima: HQC e FN-DSA devono ancora arrivare, i parametri potrebbero essere rivisti e in un'implementazione giovane potrebbe emergere un difetto. Un'organizzazione che affronta una migrazione manuale e dolorosa rivivrà lo stesso dolore la volta successiva; una che costruisce agilità trasforma il prossimo cambiamento in un rilascio di configurazione. Lo chieda in ogni acquisto: il prodotto può cambiare gli algoritmi di scambio di chiavi e di firma tramite aggiornamento o impostazione, e il fornitore si impegna a farlo? Un prodotto che non può è un problema di migrazione che sta acquistando oggi.

Sempre più spesso sì, ma va verificato prodotto per prodotto. OpenSSH ha reso predefinito uno scambio di chiavi ibrido post-quantistico con la versione 9.0 nel 2022, e la versione 10.0 del 2025 ha reso predefinito l'ibrido basato su ML-KEM, mlkem768x25519-sha256; se entrambe le estremità usano versioni aggiornate, le Sue sessioni SSH probabilmente lo usano già. Per le VPN il quadro è vario. Lo scambio di chiavi IPsec IKEv2 ha ottenuto con la RFC 9370 un modo standard per aggiungere scambi ulteriori, come ML-KEM; alcuni fornitori e progetti open source lo supportano, altri l'hanno solo annunciato. WireGuard può aggiungere una chiave simmetrica precondivisa come livello di protezione post-quantistica, ma il suo handshake resta classico. Controlli le note di rilascio del firmware del firewall o del gateway VPN e le versioni dei client effettivamente in uso, e ricordi che un vecchio server a un'estremità mantiene classica l'intera connessione. Le VPN di accesso remoto e tra sedi trasportano molti dati di lunga durata, quindi meritano un posto alto nell'ordine di migrazione.

Inizi con un inventario: certificati, VPN, TLS sui server, SSH, firma del codice e librerie usate dalle applicazioni. Il traffico di rete ne mostra una gran parte, perché lo scambio di chiavi di ogni connessione TLS è visibile senza decifrare. NQCI, l'inventario crittografico di NetSenX (in anteprima), è visibile in ogni piano e attivo dal piano Pro: mostra quali connessioni usano uno scambio di chiavi vulnerabile ai computer quantistici e quali uno scambio ibrido post-quantistico. Richiede il sensore di cattura dei pacchetti, disattivato per impostazione predefinita: attivato su un agente Linux o come sensore su una porta SPAN o TAP. La modalità di base dell'agente, usata su macOS, non vede gli handshake TLS. Dà visibilità; la migrazione resta a Lei e ai Suoi fornitori.

Una buona parte sì, ma non tutto. Ogni connessione TLS dichiara, prima che inizi la cifratura, quali gruppi di scambio di chiavi offre il client e quale sceglie il server, oltre alla versione di TLS; SSH funziona in modo simile. Un sensore che vede questi handshake può elencare, per server e per client, dove si usa ancora uno scambio di chiavi vulnerabile ai computer quantistici e dove già uno scambio ibrido post-quantistico, per ogni dispositivo del segmento, comprese stampanti, appliance e macchine che non possono ospitare un agente. Ciò che non vede: la crittografia dentro applicazioni e database, chiavi e certificati salvati su disco, la firma del codice, i backup cifrati, i segmenti non monitorati e le connessioni il cui handshake non passa mai dal sensore. NQCI, l'inventario crittografico di NetSenX (in anteprima), è visibile in ogni piano e attivo dal piano Pro; richiede il sensore di cattura dei pacchetti, disattivato per impostazione predefinita, attivato su un agente Linux o come sensore su una porta SPAN o TAP. La modalità di base su macOS non vede gli handshake. Lo combini con un inventario dei certificati e con questionari per i fornitori.

Guardi il gruppo di scambio di chiavi scelto in ogni handshake TLS: X25519MLKEM768 significa ibrido post-quantistico; X25519, secp256r1 o uno scambio di chiavi RSA significano solo classico. Un singolo server si può provare dall'esterno: OpenSSL 3.5 e successivi, e gli strumenti basati su di esso come curl, possono offrire il gruppo ibrido e mostrare cosa sceglie il server, e alcuni verificatori TLS online lo riportano. Anche gli strumenti per sviluppatori del browser mostrano il gruppo negoziato per un sito visitato. Per tutta la rete un test una tantum non basta, perché conta ciò che accade davvero ogni giorno tra client e server: client datati, appliance e applicazioni interne tornano spesso a gruppi classici. NQCI, in anteprima, lo mostra per connessione sul traffico monitorato. È visibile in ogni piano e attivo dal piano Pro, con il sensore di cattura dei pacchetti attivato su un agente Linux o come sensore SPAN o TAP, perché la modalità di base su macOS non vede gli handshake. Il risultato mostra dove gli aggiornamenti hanno già fatto la migrazione e dove resta da fare.

Per ogni punto in cui la crittografia protegge qualcosa, registri che cosa è protetto, come e chi può cambiarlo. Campi pratici: il sistema o servizio e il suo responsabile; che cosa protegge, con il tipo di dati e per quanti anni devono restare segreti; il protocollo, come TLS, SSH, IPsec, S/MIME, firma del codice o cifratura di dischi e database; gli algoritmi di scambio di chiavi, firma e cifratura, con le lunghezze delle chiavi; i certificati, l'emittente e la scadenza; la versione della libreria o del prodotto e se il fornitore ha un piano post-quantistico; e se l'algoritmo si può cambiare con la configurazione. Aggiunga una priorità ricavata dalla disuguaglianza di Mosca. Le fonti cambiano a seconda del livello: osservazione della rete per ciò che passa sul cavo, gestione dei certificati e scanner per i certificati, analisi della composizione del software e questionari per i fornitori per ciò che sta dentro le applicazioni. Un inventario con soli certificati trascura lo scambio di chiavi, e uno costruito solo dalla rete trascura i dati archiviati. Lo mantenga aggiornato, perché ogni aggiornamento può cambiare la risposta, e dati ogni voce: revisori e gare chiedono quando è stato verificato l'ultima volta.

No, e nessun prodotto di monitoraggio della rete può farlo. La protezione da un futuro computer quantistico viene dal cambiare la crittografia nei propri sistemi e in quelli dei fornitori: prima lo scambio di chiavi ibrido, poi le firme post-quantistiche. NetSenX non è un prodotto di cifratura e non cambia, aggiorna né migra nulla. Le dà visibilità, da cui parte ogni migrazione. NQCI, l'inventario crittografico di NetSenX, è in anteprima: visibile in ogni piano e attivo dal piano Pro. Mostra quali connessioni del traffico monitorato usano ancora uno scambio di chiavi vulnerabile ai computer quantistici e quali già uno scambio ibrido post-quantistico, così vede dove gli aggiornamenti hanno già fatto il lavoro e dove no, e individua in seguito le regressioni. Richiede il sensore di cattura dei pacchetti, disattivato per impostazione predefinita: attivato su un agente Linux o come sensore su una porta SPAN o TAP; la modalità di base su macOS non vede gli handshake. Non vede la crittografia dentro le applicazioni, sui dischi o nei segmenti che nessun sensore osserva.

Con fatti sul Suo piano, non con slogan. I valutatori di solito cercano quattro cose: che sappia dove usa crittografia vulnerabile ai computer quantistici, che abbia fissato delle priorità, che abbia un calendario e che qualcuno ne sia responsabile. Una risposta solida cita l'inventario e la sua data; il metodo di prioritizzazione, per esempio la disuguaglianza di Mosca applicata ai periodi di conservazione; i passi già compiuti, come lo scambio di chiavi ibrido attivato sui servizi pubblici e le versioni di VPN e SSH verificate; le dipendenze dai fornitori, con i loro piani dichiarati; e tappe allineate alla roadmap coordinata dell'UE: primi passi entro la fine del 2026 e casi d'uso ad alto rischio entro la fine del 2030. Citi per nome gli standard NIST FIPS 203, 204 e 205. Non affermi che il Suo servizio è immune agli attacchi quantistici: un valutatore informato toglierà punti. Se l'inventario deriva in parte dall'osservazione della rete, lo dica e dica che cosa non copre. Una risposta onesta e parziale, con date, ottiene più di un vuoto sicuro di sé.

Faccia domande con risposte verificabili. Quali algoritmi post-quantistici o ibridi supporta oggi il prodotto, per nome, come X25519MLKEM768 per TLS o ML-DSA per le firme, e da quale versione? Se ancora nessuno, in quale release ed entro quando? Gli algoritmi si possono cambiare con la configurazione o con un aggiornamento, senza sostituire l'hardware? Quale libreria crittografica usa il prodotto e chi la mantiene? L'hardware, come un firewall, un modulo di sicurezza hardware o un controllore, ha la capacità per chiavi più grandi o andrà sostituito? Come firmerà il fornitore i propri aggiornamenti quando cambieranno gli algoritmi di firma? Il prodotto continuerà a funzionare durante la transizione con client che supportano solo algoritmi classici? Chieda le risposte per iscritto, con date. Diffidi delle risposte che promettono immunità dagli attacchi quantistici o che parlano solo di crittografia simmetrica: eludono la vera domanda. Un fornitore che non sa rispondere è una dipendenza da considerare nel piano, e la sua risposta va nel Suo inventario.