®
01
密钥交换与签名分开迁移
ML-KEM 通过封装机制用于密钥协商；ML-DSA 和 SLH-DSA 则是签名算法。这两类任务不能互相替代。具体的协议集成，必须得到相关组件的支持。因此，我们会分别检查连接建立、身份认证和已存储制品这几个环节。在混合方案中，经典算法和后量子算法组件会依据各自协议进行组合。允许使用的经典回退方式会被清楚标明，避免一条能够正常连接的通道被误判为已经完成迁移。
您对 OTOKO® 的委托
我们为您承接的工作。
如果数据库要求固定的签名长度，或者客户端无法处理新证书，那么仅仅可以更换算法名称并没有太大帮助。我们会检查调用方式、存储格式、协议字段和密钥标识符。密码学相关任务会通过合适的库和定义清晰的接口加以整合。这样一来，也无需自行开发密码学算法。新的参数和密钥类型需要经过受控审批，而不是由用户随意选择。
可能的服务范围
- 分析硬编码的算法和格式假设
- 梳理密码学调用和相关配置
- 集成受支持的库和提供程序（Provider）
- 检查协议兼容性和允许的回退方式
- 准备回归测试和受控的上线部署
具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。
把技术讲清楚
我们是这样落实任务的。
02
使用真实对接系统进行测试
验收环节会使用具有代表性的客户端、网关和库。无效密钥、不受支持的参数以及过时的对接系统，都属于测试范围。数据格式必须能够清楚地反映日后的算法更换。您的团队将获得相应的改动内容、已记录的限制条件和回归测试。具体的软件版本会在项目中逐一核实，而不是仅凭产品系列来推断其支持情况。
一个可验证的成果
这将成为您后续工作的基础。
- 密码学绑定关系分析
- 完成调整的应用或试点集成
- 测试与迁移计划
移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。
您的项目详情
能够更换算法，而无需重新构建整个产品。
我们会排查算法、密钥长度和数据格式在您的软件中被硬性固定的位置，然后建立合适的技术边界，使新算法能够以受控的方式引入。
将密码学决策与业务逻辑解耦
硬编码的假设并不只存在于实际的密码学调用之中。数据库字段、文件格式和接口也可能预设了固定长度或特定的密钥类型。我们会连同程序库和配置一起审查这些环节，避免更换工作因为一个看似无关的存储字段而受阻。
抽象化并不意味着自行发明一套密码学库。经过验证的实现会通过一个清晰易懂的接口被整合进来。允许使用的算法和参数始终受到管控；不能让不受信任的输入随意选择算法，从而取代安全决策。
规划过渡阶段与向后兼容性
现有数据或通信对象可能仍然需要使用旧算法。我们会设计一套清晰可辨的版本机制，并核查哪些并行运行状态真正得到支持。任何回退到旧算法的行为，都不允许被攻击者或出错的对接系统悄然触发。
针对每一种受支持的组合，都会制定相应的测试和发布标准。不再被允许使用的算法，必须能够被有针对性地停用。这样一来，密码敏捷性就成为一套持续维护、边界清晰的变更流程，而不是一堆不受控制的选项堆砌。
示例项目场景
该服务在日常工作中如何发挥作用。
示例：某应用将签名存储在一个假定长度固定的字段中。我们会解除这种绑定关系，对格式进行版本化处理，并检验新旧数据记录的生成与校验。真正的算法切换，要等到整条处理链路的支持都得到确认之后才会进行。
该示例说明的是一种可能的流程，并非客户案例。
在迈出第一步之前
您关于 密码敏捷性 的问题。
是否每个使用最新版本库的应用都自动具备 PQC 能力？
不是。应用必须实际使用合适的算法，支持相应的格式，并能与对接系统互操作。
旧客户端是否仍可以使用传统加密方式连接？
这是针对具体服务做出的有意识的风险决策。我们会记录此类过渡过程，并明确标示哪些连接尚未达到目标级别。
