FIPS 203 in italiano
Salta al contenuto
Quantum Horizon<br>Il portale italiano sul computer quantistico e le tecnologie emergenti
News Quantistiche
FIPS 203 in italiano: perché ho tradotto lo standard ML-KEM e cosa ci ho messo intorno
di<br>Remo Pulcini
·<br>Agosto 12, 2026
Il problema non è che lo standard sia difficile. È che è scritto per qualcun altro.
Chi lavora nella pubblica amministrazione italiana e si trova davanti alla transizione post-quantistica affronta un ostacolo che non è tecnico ma di traduzione in senso letterale e in senso figurato.
FIPS 203, lo standard NIST che definisce ML-KEM, è il documento che ogni amministrazione dovrà conoscere per mettere mano ai propri sistemi crittografici. È pubblicato dal National Institute of Standards and Technology, esiste solo in inglese, ed è scritto nel registro tipico degli standard federali statunitensi: novanta pagine di prescrizioni normative, notazione matematica, pseudocodice e tabelle di parametri. È un documento eccellente per il suo scopo dice a un implementatore esattamente cosa deve fare per scrivere codice conforme.
Ma il funzionario italiano che deve redigere un capitolato, il responsabile della transizione digitale che deve pianificare una migrazione, il dirigente che deve motivare un investimento davanti a un direttore generale: nessuno di questi legge FIPS 203 per implementarlo. Lo legge per capire cosa comporta, con quali tempi, sotto quale responsabilità, e come si scrive un requisito che un fornitore non possa aggirare.
Quel documento non esiste. O meglio: non esisteva.
Cosa ho fatto
Ho tradotto integralmente FIPS 203 in italiano e ho scritto intorno alla traduzione una guida applicativa pensata per il contesto della pubblica amministrazione italiana. Il risultato è un volume che contiene due cose distinte, deliberatamente tenute separate.
La prima parte è la traduzione integrale dello standard . Non un riassunto, non una parafrasi divulgativa: il testo completo, sezione per sezione, con formule, pseudocodice e tabelle dei parametri. La seconda è la guida applicativa , che è materiale originale e risponde alle domande che lo standard, giustamente, non si pone: chi deve fare cosa, entro quando, con quali riferimenti normativi italiani ed europei, e come si traduce tutto questo in un documento amministrativo.
Perché la traduzione è lecita, e perché è un dettaglio importante
Vale la pena spiegarlo, perché è una domanda che mi è stata posta più volte e che riguarda chiunque voglia lavorare su questi materiali.
Le opere prodotte dal governo federale statunitense non godono di protezione di copyright negli Stati Uniti, ai sensi del 17 U.S.C. § 105. I documenti NIST sono di pubblico dominio: chiunque può tradurli, riprodurli, farne opere derivate, anche a scopo commerciale. Non serve autorizzazione.
La situazione è opposta per gli standard prodotti da organizzazioni private di standardizzazione ETSI, ISO, IEC, CEN, UNI. Quelli sono protetti dal diritto d’autore, e il fatto che alcuni siano scaricabili gratuitamente non significa che siano liberamente riproducibili o traducibili: sono due cose diverse, e la confusione tra le due è all’origine di parecchi problemi.
Per questa ragione il volume lavora esclusivamente su materiale NIST . Dove servono riferimenti a standard di altri enti, questi vengono citati e descritti, mai riprodotti. È una scelta che non impoverisce l’opera, perché il valore per il lettore italiano non sta nel testo dello standard: sta nel capire cosa farne.
Va detto con chiarezza anche il rovescio: essendo il testo originale di pubblico dominio, chiunque può tradurlo. Non rivendico un’esclusiva su un diritto che non esiste. Quello che offro è una traduzione fatta con criteri espliciti, verificata a mano, e accompagnata da un apparato che non deriva dal NIST ma dall’esperienza di chi lavora dentro la pubblica amministrazione italiana.
I criteri di traduzione, e perché contano più di quanto sembri
Tradurre uno standard normativo non è tradurre un testo tecnico qualunque. Ci sono due punti dove una scelta sbagliata produce danno reale.
Il primo sono i verbi modali. In un documento FIPS, shall esprime un obbligo, should una raccomandazione, may una facoltà. Sono livelli di cogenza diversi, e la differenza ha conseguenze pratiche: in un capitolato d’appalto, un requisito espresso come obbligo e uno espresso come raccomandazione producono esiti opposti in caso di contestazione. Nella traduzione ho adottato una resa rigida e invariabile shall è sempre "deve", should è sempre "è opportuno che" o "si raccomanda di", may è sempre "può" senza mai variare per ragioni stilistiche. La leggibilità ne soffre un poco. La precisione no.
Il secondo è la terminologia tecnica. Ho scelto deliberatamente di non italianizzare i termini che il lettore troverà scritti in inglese nella documentazione dei fornitori, nelle configurazioni software e nei capitolati internazionali. ML-KEM resta ML-KEM. Seed resta seed. NTT resta...