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.
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.
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"
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.
- NISTStandard FIPS 203 (ML-KEM) — [NIST]
- IETFScambio di chiavi ibrido in TLS — [specifica]
- 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.