Tässä aiheessa
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.
Lue opas ENUutisseuranta
Kaikki kansainväliset uutiset →Syötteet eivät ole tilapäisesti saatavilla. Avaa alkuperäiset lähteet tai yritä myöhemmin.
Lähteet: tiedot, käyttö ja rajat
Aineisto tarkistettu .
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
| Lähde ja tarkoitus | Tarkistettu tieto tai vertailukohta | Käyttö käytännössä | Huomioitava rajoitus |
|---|---|---|---|
| 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. |
Postkvanttisalaus: vertaa ennen siirtymää
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
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, HTTP-välimuisti ja samanaikaiset muutokset
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
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 ja tuotteen soveltuvuus
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
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
Koosteen allekirjoitus ja alkuperä
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
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