行动清单
- 01
Inventory cryptography
Identify protocols, certificates, signatures, libraries, hardware and owners. Include hidden dependencies in software and managed services. Do not limit the inventory to HTTPS traffic. Examine update signatures, service-to-service communication, encrypted backups, embedded equipment and remote access. Record versions and interfaces that allow algorithm changes.
- 02
Classify sensitivity lifetimes
Identify information that must remain confidential for years and systems that are difficult to replace. Document assumptions without predicting a certain date for a relevant quantum computer. Distinguish a file’s retention period from how long its contents must remain confidential. A long-lived system may require earlier preparation than a frequently replaced application. Make these assumptions explicit.
- 03
Follow original standards
Consult NIST publications and national authority guidance. Distinguish final standards, drafts and commercial offerings. For each choice, record the organisation, reference, version and document status. Check usage profiles relevant to the environment. Compatibility announced in a sales presentation is not documented production support.
- 04
Ask suppliers
Request a migration roadmap, client compatibility and hardware limits. Check contractual commitments and actual availability of announced features. Ask which component performs the cryptographic operation, which client versions are required and how to restore a working state. Link the answer to an inventory dependency rather than a general compliance statement.
- 05
Test without inventing cryptography
Use maintained implementations in a test environment. Measure interoperability, message sizes, performance and rollback mechanisms. Define a reference transaction and compare success, errors, timing and sizes on representative clients. Test network intermediaries and constrained equipment. Retain the exact configuration to separate incompatibility from measurement error.
- 06
Build a staged migration
Prioritise services, set acceptance criteria and retain test evidence. Plan crypto-agility so algorithms can change without rebuilding the entire system. Plan a reversible pilot, results review and dependency-based rollout. Define who authorises transition and monitors failures. Accept migration only when critical uses remain verified in the target configuration.
Worked example: a supplier proposes a cryptographic migration. Ask which exchanges and libraries change, which devices remain compatible and how to restore the previous configuration. Test connection setup, errors, performance and recovery. A post-quantum label alone is not evidence that the whole system has been integrated correctly.
参考资料：数据、用途与局限
文档核查日期 .
此语言版本的详细参考说明以英语提供。
| 来源与目的 | 已核实的数据或指标 | 使用方法 | 需要保留的局限 |
|---|---|---|---|
| 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. |
后量子密码：迁移前先比较
此语言版本的详细参考说明以英语提供。
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 缓存与并发更新
此语言版本的详细参考说明以英语提供。
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 与产品适用性
此语言版本的详细参考说明以英语提供。
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
构建签名与来源
此语言版本的详细参考说明以英语提供。
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