分离签名与文件完整性验证

目标与适用范围

为已知文件生成或复现哈希，与发布方 checksum 对照，并使用单独确认信任来源的 Ed25519 公钥验证分离签名。
本指南将当前任务范围转化为可复核的交付结果。请保留源文件、中间产物和关键判断，让后续协作者能够理解检查了什么以及为什么这样处理。

准备证据并作出选择

• 使用文件的原始字节或已批准的证据副本；在打开或编辑前记录文件名、版本、来源和传输步骤。

• 准备发布方给出的期望摘要或 checksum、算法、分离签名，以及签名时使用的准确文本或字节表示。

• 通过独立的可信渠道确认公钥指纹，并预先确定摘要不一致或签名无效时的发布、接收和升级处理方式。

• 不要把私钥输入本工作流；验证只需要公钥、签名和被签名载荷。

• 决策点: 你要证明的是完整性、真实性，还是两者都要？. 哈希一致只能说明被检查的字节与参考摘要一致，不能说明文件由谁生成。只有在签名载荷准确且公钥信任决定正确时，签名才可支持签名者真实性。

• 决策点: 分离签名覆盖的究竟是哪一种载荷？. 先确认签名覆盖原始文件字节、规范化文本、manifest 还是摘要字符串，然后验证同一种表示。换行符、编码、空白或序列化方式的变化，都可能让检查失去意义。

• 决策点: 哪个摘要比较结果才是依据？. 使用发布方声明的算法；只在不改变摘要内容的前提下统一大小写和展示格式。不能用另一种算法或复制错误的值制造通过结果。

按步骤完成工作流

1. 为准确的文件副本计算哈希

使用未修改的文件和发布方声明的算法。记录计算出的摘要、文件名、大小和期望值；从取得文件到计算完成之间不要编辑制品。 使用 file-hash-verifier.

2. 复现签名载荷的摘要

如果签名对象是规范化文本、manifest 或摘要字符串，而不是直接上传的文件，就按签名规范复现完全相同的表示并计算摘要。除非规范明确如此，否则不要把文本摘要与文件字节摘要混为一谈。 使用 hash-generator.

3. 对照发布方 checksum

比较本地计算值和独立取得的 checksum，先确认两者算法相同并且指向同一制品。出现差异时保留差异详情，不要用替代文件覆盖证据。 使用 checksum-comparator.

4. 验证 Ed25519 分离签名

将准确的签名消息表示、分离签名和公钥送入验证。记录布尔结果，并另外确认公钥指纹来自可信渠道；不受信任的公钥即使验签成功，也不能形成可接受的来源结论。 使用 ed25519-x25519-keygen-signature-verifier.

交付前验收结果

• 证据记录明确标出文件或签名载荷、使用的算法、期望 checksum 的来源，以及送入验签的载荷表示。
• 本地计算的摘要与发布 checksum 在同一算法下匹配；若不匹配，必须保留为失败的完整性结果，不能静默重试。
• 分离签名在准确的签名载荷上验证通过，并且公钥指纹及其信任来源被单独记录。
• 最终决定分别报告完整性、签名有效性和公钥信任状态，绝不把哈希一致单独当成来源证明。

常见问题

• checksum 匹配能证明文件来自声称的发布方吗？ 不能。它只说明文件字节与参考值一致；参考值本身可能错误或被替换，所以发布方身份还需要可信的签名公钥或分发渠道。
• 签名工具可以直接验证任意二进制文件吗？ 只有在你能提供工具接受的、与签名时完全相同的消息表示时才可以。原始字节、规范化文本、Base64 文本和签名 manifest 是不同输入，不能猜测或擅自转换。
• 验证分离签名需要哪些材料？ 需要签名、准确的被签名载荷、匹配的算法和编码、公钥，以及通过独立渠道确认的公钥指纹或信任来源。
• 哈希或签名失败时应该怎么办？ 保留原始证据，记录算法和输入并暂停验收决定。通过批准的渠道检查传输、编码、载荷选择和公钥来源，不要不断换文件直到出现通过结果。