On August 13, 2024, the U.S. National Institute of Standards and Technology (NIST) published FIPS 203, the federal standard defining ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). It is the first officially approved key-establishment mechanism explicitly designed to withstand attacks from a sufficiently powerful quantum computer. For anyone working in information security, this is not a minor technical footnote it is the formal starting point of the global transition to post-quantum cryptography.
A year later, the document remained accessible in full only in English: seventy dense pages of pseudocode, mathematical notation, and normative requirements written with legal precision, where “shall,” “should,” and “may” carry distinct, non-interchangeable obligations. I have produced a complete Italian translation of FIPS 203, with an editorial apparatus and a reading guide designed not for the academic cryptographer, but for the people who need to understand this standard well enough to plan for it, specify it in a procurement document, or evaluate whether a vendor’s claim of “post-quantum readiness” actually holds up.
Why post-quantum cryptography stopped being a specialist concern #
For decades, the security of digital communications encryption, digital signatures, key exchange has rested on mathematical problems that classical computers cannot solve in any practical amount of time: factoring very large integers, computing discrete logarithms. A sufficiently powerful quantum computer, using Shor’s algorithm, would solve these problems dramatically faster, effectively breaking the cryptographic algorithms most widely deployed today, including RSA and elliptic-curve cryptography. This is not a distant, speculative risk. It already has a name in the security community: “harvest now, decrypt later.” An adversary can intercept and store encrypted communications today, betting on being able to decrypt them once quantum computing matures. For data with a long shelf life — medical records, legal and judicial documents, diplomatic communications, industrial secrets, government data — this means the exposure window is already open, regardless of exactly when a cryptographically relevant quantum computer is actually built.
In 2016, NIST launched a public, multi-year selection process to identify quantum-resistant cryptographic algorithms. Out of 82 initial submissions, after three rounds of evaluation, the first approved standards were selected. ML-KEM, derived from the CRYSTALS-KYBER algorithm, is one of them. Its security rests on the computational hardness of the Module Learning With Errors problem a problem defined over mathematical structures called lattices, currently believed to remain hard even for an adversary equipped with a quantum computer.
Why this needed a translation, not just a summary #
Professionals working in Italian public administration, public healthcare, legal compliance, or technical consulting are often caught between two unsatisfying options: rely on popular summaries that simplify — ometimes inaccurately an already complex subject, or work directly from the original normative text in a language that isn’t their own, on a topic that is technically demanding even in one’s native tongue. A summary is fine for getting a general sense of the subject. It is not fine when you need to draft a technical specification, evaluate a security vendor’s proposal, or simply determine whether a product’s “post-quantum compliant” claim is actually accurate.
That is why this translation is not a paraphrase: it is the complete text of FIPS 203, including every algorithm in pseudocode (left identical to the original pseudocode isn’t translated, it’s implemented), the parameter tables, the bibliographic references, and the technical appendices, including the precomputed values for the Number-Theoretic Transform that underpins ML-KEM’s computational efficiency.
To this I added three elements the NIST text, understandably, does not provide:
A differentiated reading path. Not every reader needs the same level of detail. Someone who has to make a decision plan an adoption, draft a specification, evaluate a vendor mainly needs the introduction, the high-level overview of the ML-KEM scheme, the chapter on the mechanism itself, and the parameter-set section, which also contains NIST’s official recommendation (ML-KEM-768 as the default choice) along with the concrete sizes of keys and ciphertexts, useful for sizing real systems. Someone who needs to validate an implementation needs everything else, in the right order, since each chapter builds on conventions established in the ones before it.
A consistent terminology glossary. Translating cryptographic terminology into Italian requires choices that are not obvious and, more importantly, choices that stay consistent across the entire document: the distinction between “encapsulation key” and “decapsulation key,” between “ciphertext” and “plaintext,” and the handling of normative verbs (English “shall” carries a different legal force than “should,” and that distinction has to be preserved in Italian with the same precision).
Editorial transparency. The document explicitly marks what is a faithful translation and what is an added editorial note, so that anyone using it as a normative reference always knows which is which. In case of any discrepancy, only the official English NIST text is authoritative.
Who this is actually for #
The intended reader is an Italian technical-administrative professional: an IT director or manager in public administration, a Digital Transition Officer, a cybersecurity consultant, someone evaluating technical bids in a procurement process. It is not written for someone who needs to implement the cryptographic code directly that person will still need to work from the official English text, as is appropriate for any critical cryptographic parameter — but for someone who needs to understand, decide, and verify, without necessarily being a cryptographer.
It is no coincidence that ML-KEM is already making its way, in various forms, into the security requirements of software, browsers, TLS protocols, and the technology roadmaps of major vendors. The post-quantum transition will not wait for organizations to be ready; it only waits for the first standards to be published, and that has already happened. Anyone in Italy responsible for deciding which cryptographic requirements to write into a specification, which questions to ask a vendor, or how to plan the upgrade of systems with a long operational lifespan, needs to be able to make those judgments against the actual normative text — not a secondhand summary of it.
What “migrating” actually means in practice #
A common mistake, when discussing the post-quantum transition, is imagining it as a switch to be flipped on a specific day: today RSA, tomorrow ML-KEM. That is not how existing infrastructure actually works, and the standard itself reflects this. FIPS 203 specifies three parameter sets ML-KEM-512, ML-KEM-768, ML-KEM-1024 with different trade-offs between security strength and performance, precisely because not every system has the same bandwidth constraints, computational budget, or data sensitivity.
In practice, most organizations seriously engaging with this transition are adopting “hybrid” schemes: the new post-quantum primitive is combined with, not simply substituted for, the classical algorithms already in use, so that overall system security never drops below the current baseline even in the unlikely but non-zero scenario that an unexpected weakness is later found in the new algorithm. This is a deliberately conservative approach, and it’s part of why the standard devotes an entire section to implementation requirements: destruction of intermediate values, mandatory input verification, a prohibition on floating-point arithmetic in critical computations. These details can look marginal until someone is drafting a technical specification and realizes that’s exactly where the difference lies between a vendor who has actually read the standard and one who is merely citing its name.
There is also the matter of what the security community calls “crypto-agility”: an organization’s ability to update its cryptographic mechanisms without redesigning its entire infrastructure from scratch. Anyone planning a system today even without an immediate intention to migrate to ML-KEM should be asking whether the architecture being approved will allow for that kind of update later, or whether it implicitly locks the organization out of it for years. This is another reason the standard matters to decision-makers, not only to implementers: the right architectural decision has to be made early, well before the regulatory deadline is actually at the door.
A note on rights #
The original English text of FIPS 203 is a work of the United States federal government and, as such, is not subject to copyright in the United States. It is freely available on NIST’s website. The Italian translation presented here including terminology choices, the working glossary, and editorial curation constitutes an original creative work, protected by copyright as the translator’s own independent contribution, regardless of the public-domain status of the source text. This is not an official translation, and it has not been commissioned or endorsed by NIST. In case of any discrepancy, only the official English text is authoritative.
In short #
FIPS 203 is not a document that can afford to remain out of reach for the people who will actually have to translate its requirements into real decisions: procurement specifications, vendor evaluations, and infrastructure planning on long time horizons. This book exists to close exactly that gap between an international technical standard and the people, in Italian public administration and the private sector alike, who will need to apply it before it becomes an urgent problem rather than something planned for in time.