In questo argomento
Post-quantum cryptography · IoT · OT / ICS · Robotics · Semiconductors
Prepare a post-quantum cryptography transition
How should a post-quantum migration be prepared? Start with a cryptographic inventory, then classify uses by data sensitivity and system replacement difficulty. Check standards status and capabilities actually delivered by suppliers. The roadmap connects each service to its dependencies, interoperability tests, rollback criteria and owner. There is no single migration deadline that applies to every environment.
Leggi la guida ENMonitoraggio delle notizie
Tutte le notizie internazionali →Titoli salvati · aggiornamento non disponibile · Ultimo recupero riuscito : 22 ott 2026, 21:21
Quantum computing, come costruire una filiera: il caso IonQ - Agenda Digitale
via Google News · aggregatorBofA Securities individua i migliori titoli del quantum computing - Investing.com
via Google News · aggregatorIBM e il quantum computing: chip, Qiskit, cloud e obiettivi al 2029 - Agenda Digitale
via Google News · aggregatorMappa del mercato quantum computing: aziende, startup e investimenti in Italia ed Europa - Agenda Digitale
via Google News · aggregatorQuanto ci vorrà perché il quantum computing diventi realtà - TradingView
via Google News · aggregatorIl supercomputer europeo che sta accorciando la strada verso il quantum computing - Hardware Upgrade
via Google News · aggregatorRiferimenti: dati, usi e limiti
Documentazione consultata il .
Le note dettagliate di questa edizione sono disponibili in inglese.
| Fonte e finalità | Dato o riferimento verificato | Come utilizzarlo | Limite da conservare |
|---|---|---|---|
| SPDX · Specifications Describe components and information in a software bill of materials. |
The official specifications page distinguishes SPDX 3.0 from earlier versions such as 2.3. Document version affects schema and tool compatibility. | Request format, version, build scope and component identifiers. Compare the bill of materials with the delivered artefact. | A bill of materials alone proves neither vulnerability absence, dependency completeness nor compliance with every licence. |
| OWASP · CycloneDX Exchange bills of materials and supply-chain information. |
The official overview dates specification 1.7 to 21 October 2025 and documents JSON, XML and Protobuf. | Check version, component references and dependency links. Retain the connection between the bill of materials, build and deployed product. | Changing format does not fix missing components. A descriptive inventory and a vulnerability impact assessment answer different questions. |
| NIST · Post-quantum cryptography Identify standards relevant to cryptographic transition. |
NIST distinguishes FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA. Key encapsulation and signatures are different functions. | Inventory protocols, libraries, keys and dependencies. Ask which versions are actually implemented and test interoperability, performance and rollback. Compare post-quantum parameters and estimate their volumes → |
Having a standardised algorithm does not establish security of the complete integration or a universal migration deadline. |
Crittografia post-quantistica: confrontare prima di migrare
Le note dettagliate di questa edizione sono disponibili in inglese.
ML-KEM establishes a shared secret; ML-DSA and SLH-DSA sign data. These functions serve different needs. The 18 parameter sets below come from the three final FIPS standards published on 13 August 2024. Use them to prepare inventories and capacity tests without treating an algorithm name as proof of a secure system.
Data and publication status pages checked on .
ML-KEM · Establish a secret
- The recipient publishes an encapsulation key.
- The sender creates a ciphertext and shared secret, then sends the ciphertext.
- The recipient recovers the secret using a decapsulation key.
Peer authentication and use of the secret depend on the complete protocol.
ML-DSA / SLH-DSA · Sign
- The signer protects a private key and distributes a public key.
- The signer signs data and sends the data with its signature.
- The verifier checks the signature using the trusted public key.
A signature alone does not encrypt the signed content.
For ML-KEM, the public and private keys are used for encapsulation and decapsulation respectively; column five is the ciphertext. For both DSA families, the keys are used for verification and signing; column five is the signature. A dash means not applicable. NIST categories are neither quality ratings nor key lengths in bits.
| Parameter set / source | NIST category | Public key | Private key | KEM ciphertext / signature | Shared secret |
|---|---|---|---|---|---|
| ML-KEM-512FIPS 203 | 1 | 800 | 1,632 | 768 | 32 |
| ML-KEM-768FIPS 203 | 3 | 1,184 | 2,400 | 1,088 | 32 |
| ML-KEM-1024FIPS 203 | 5 | 1,568 | 3,168 | 1,568 | 32 |
| ML-DSA-44FIPS 204 | 2 | 1,312 | 2,560 | 2,420 | — |
| ML-DSA-65FIPS 204 | 3 | 1,952 | 4,032 | 3,309 | — |
| ML-DSA-87FIPS 204 | 5 | 2,592 | 4,896 | 4,627 | — |
| SLH-DSA-SHA2-128sFIPS 205 | 1 | 32 | 64 | 7,856 | — |
| SLH-DSA-SHA2-128fFIPS 205 | 1 | 32 | 64 | 17,088 | — |
| SLH-DSA-SHA2-192sFIPS 205 | 3 | 48 | 96 | 16,224 | — |
| SLH-DSA-SHA2-192fFIPS 205 | 3 | 48 | 96 | 35,664 | — |
| SLH-DSA-SHA2-256sFIPS 205 | 5 | 64 | 128 | 29,792 | — |
| SLH-DSA-SHA2-256fFIPS 205 | 5 | 64 | 128 | 49,856 | — |
| SLH-DSA-SHAKE-128sFIPS 205 | 1 | 32 | 64 | 7,856 | — |
| SLH-DSA-SHAKE-128fFIPS 205 | 1 | 32 | 64 | 17,088 | — |
| SLH-DSA-SHAKE-192sFIPS 205 | 3 | 48 | 96 | 16,224 | — |
| SLH-DSA-SHAKE-192fFIPS 205 | 3 | 48 | 96 | 35,664 | — |
| SLH-DSA-SHAKE-256sFIPS 205 | 5 | 64 | 128 | 29,792 | — |
| SLH-DSA-SHAKE-256fFIPS 205 | 5 | 64 | 128 | 49,856 | — |
Sizes refer to the raw encodings defined by the standards. A private key stored as a seed may occupy less space than the full encoding shown here. Certificates, containers, Base64, protocol headers and protected storage add their own bytes. In SLH-DSA, ‘s’ favours smaller signatures and ‘f’ faster signing; SHA2 and SHAKE variants share sizes for each variant, rather than the same hash instantiation.
Estimate a volume of cryptographic data
Choose a parameter set and object count. The calculation adds raw public sizes only: one KEM ciphertext or signature per object, with a public key sent once or repeated for every object. Private keys and shared secrets are excluded from the modelled transfer.
A numerical example for planning a test
For 1,000 ML-KEM-768 objects with a public key for every object: 1,000 × (1,184 + 1,088) = 2,272,000 raw bytes. With one public key for the whole batch: 1,184 + 1,000 × 1,088 = 1,089,184 bytes. This is an illustrative transport assumption, not a service or protocol measurement.
This volume model measures neither computation time, throughput, TLS latency nor security. The single-key mode assumes the same recipient or verifier can reuse that key under the chosen protocol. Check this assumption, key rotation and size limits in your environment. This tool sends no content, keys or entered data.
What evidence should a pilot require?
| Use to inventory | Information to record | Useful test and decision condition |
|---|---|---|
| Exchanges and confidential data | Application, protocol, library and version; key establishment function; data sensitivity lifetime; intermediary equipment. | Replay connections on an authorised test platform, record errors and volumes, verify which peers actually interoperate and how to restore the approved configuration. |
| Software signing and updates | Build chain, signed format, keys and embedded verifiers; ability to renew the root of trust. | Verify a valid package and then a modified package. Measure the final manifest size and confirm that older devices have an update path. |
| Certificates and machine identities | Authorities, certificate profiles, signature algorithms, trust stores and external dependencies. | Check issuance, renewal and revocation in the products concerned. Library support for an algorithm does not by itself prove support for the full certificate. |
| Backups, archives and retention | Formats, keys needed for restoration, custody responsibilities and versions able to read historical objects. | Restore an old sample in the target environment and preserve the necessary verification material. Migrating connections does not automatically re-encrypt stored archives. |
Decision questions
Does ML-KEM replace a signature?
No. Encapsulation establishes a shared secret. Signatures support checks of data integrity and origin under the chosen trust mechanism. A project may need to migrate these two functions separately.
Is the smallest object the best choice?
Size addresses one capacity constraint. Selection must also consider security requirements, maintained implementations, compatibility and test results. The comparison does not rank algorithms.
Is a product described as ‘FIPS 203’ automatically certified?
A standard reference identifies an algorithm specification. Request separate evidence of any claimed conformity or validation, its exact scope, the module version and the configuration assessed.
Why check publication status pages as well as the standard?
NIST status pages identify potential updates: notes dated 17 November 2025 for FIPS 203 and 31 July 2026 for FIPS 204 at this review. Ask suppliers which corrections their release incorporates.
Value provenance and freshness limits
Links lead to official publication notices and histories. Sizes come from the tables identified below; SLH-DSA private key sizes are calculated using the 4n rule in §3.1. Scope is limited to parameter sets in FIPS 203–205: this is not a catalogue of all post-quantum research, proposals or protocol profiles.
- NIST FIPS 203 · ML-KEM · §8, tables 2–3; §8 security categories
Standard publication : · Potential update note : - NIST FIPS 204 · ML-DSA · §4, tables 1–2
Standard publication : · Potential update note : - NIST FIPS 205 · SLH-DSA · §11, table 2; §3.1: private key = 4n bytes
Standard publication :
ETag, cache HTTP e modifiche concorrenti
Le note dettagliate di questa edizione sono disponibili in inglese.
Three consistency checks before release
Read freshness and user isolation must be tested against the variants actually served.
- Trace a conditional GET → 304, then a resource change → 200.
- Apply access refusal before the ETag condition for a protected resource.
- Test a stale write: 412 with no actual modification.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
VEX e applicabilità al prodotto
Le note dettagliate di questa edizione sono disponibili in inglese.
Request an applicability assertion matching the delivered product
A supplier may provide an SBOM and VEX document whose scope does not match your build. Connect those records to the vulnerability, delivered version and explicit status conditions.
- Check issuer, product identifiers, version, time and inherited information in the complete document.
- Request not_affected justifications or affected actions; preserve under_investigation as uncertainty.
- Review the assertion when the build, dependencies or execution assumptions change.
Read VEX statuses and applicability conditions →
Sources checked on · OpenVEX · Specification v0.2.0
Firma e provenienza del build
Le note dettagliate di questa edizione sono disponibili in inglese.
Request interpretable provenance evidence
Supplier evidence becomes useful when its content and scope match a delivered product. Trust needs an authorised identity and platform, with explicit expectations for production.
- Identify artefact, digest, attestation format and provenance distribution method.
- Distinguish a declared SLSA Build level from actual assessment of requirements and platform trust.
- Record unresolved fields and dependencies; an empty list does not establish their absence.
Read the pre-deployment provenance reference →
Sources checked on · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures

