Edizione globaleN° 001 · Pacific IT
UMBRA Osservatorio sulle minacce digitali
CrittografiaML-KEMMIGRAZIONE

Passare a ML-KEM: cosa cambia davvero per i siti sicuri, le firme digitali e i firmware

Dalla teoria alla pratica della crittografia post-quantum: chiavi più grandi, un po' più di lavoro per i server, e una strategia graduale per non rompere nulla mentre si cambia.

Redazione UMBRA14 Nov 2026 · 08:50Pratica
Scheda elettronicaFOTO · B/N
Hardware crittografico. Immagine d'archivio, rielaborata in bianco e nero.

Abbiamo spiegato perché serve la crittografia post-quantum. Qui guardiamo il come: cosa succede in pratica quando si sostituisce il vecchio scambio di chiavi con il nuovo, chiamato ML-KEM (ex Kyber). Perché cambiare algoritmo non è indolore, anche se è gestibile.

La prima differenza concreta sono le dimensioni. Le chiavi e i messaggi di ML-KEM sono più grandi di quelli attuali: non enormi, ma nell'ordine dei kilobyte invece dei pochi byte di prima. Su una singola connessione non si nota; su un server che ne gestisce milioni al secondo, quel «di più» di banda e di calcolo va pianificato.

Siti sicuri (TLS 1.3)
Scambio di chiavi «ibrido»: X25519 vecchio + ML-KEM nuovo
Dimensioni
Chiavi e messaggi nell'ordine dei kilobyte
Firme e certificati
Da rivedere con il nuovo standard di firma (ML-DSA)
Firmware
Firme a lunghissima durata: priorità alta

La crittografia che deve durare a lungo — i firmware, gli archivi, le identità di base — è quella da migrare per prima.

Perché si cambia a metà, non tutto in una volta

La strategia raccomandata è ibrida e graduale. Ibrida vuol dire usare i due metodi insieme, come abbiamo spiegato: così se uno dei due cede, l'altro tiene. Graduale vuol dire attivare il nuovo scambio solo dove i programmi dall'altra parte lo supportano, mantenendo la compatibilità con chi ancora non è pronto. Si evita così di rompere le connessioni mentre si migra.

La priorità va data a ciò che deve restare segreto per molti anni. Una sessione web di oggi, se anche fosse intercettata e decifrata tra quindici anni, probabilmente non interesserà a nessuno. Un firmware firmato che deve essere valido per vent'anni, o un archivio di documenti riservati, sì.

Verificare a che punto si è

Anche qui il primo passo è conoscere lo stato attuale. Questi comandi dicono se un server parla già la nuova lingua e con quale algoritmo di firma è costruito un certificato:

# Controlla se il server negozia lo scambio ibrido post-quantum
openssl s_client -connect <host>:443 -groups X25519MLKEM768

# Mostra l\u2019algoritmo di firma di un certificato
openssl x509 -in cert.pem -noout -text | grep "Signature Algorithm"
Comandi di verifica difensiva del supporto post-quantum.

Perché conta. Non bisogna migrare tutto domani mattina, ma bisogna cominciare: fare l'inventario, stabilire le priorità, attivare il supporto ibrido dove già si può. Chi parte adesso avrà anni per farlo con calma; chi aspetta si troverà a rincorrere, con i segreti più preziosi già esposti.

Fonti & riferimenti
  1. NISTStandard FIPS 203 (ML-KEM) — [NIST]
  2. IETFScambio di chiavi ibrido in TLS — [specifica]
  3. VENDORSupporto post-quantum nei prodotti — [fornitore]

UMBRA riscrive e sintetizza fonti di pubblico dominio con parole proprie, citando e collegando gli originali. Numeri CVE, versioni e IOC in questa pagina di template sono illustrativi finché l'aggregatore non li popola dai feed reali. Non vengono forniti exploit o codice d'attacco: gli script mostrati sono di verifica difensiva, detection e threat hunting.

← Torna alla prima pagina