签名和校验和，回答的不是同一个问题

校验和能说明什么

SHA-256 这类密码学哈希，会确定性地把文件字节映射成固定长度摘要。如果你的副本生成的摘要与预期值不同，它就不匹配该参照。这有助于发现传输损坏或无意修改，前提是你知道预期值对应哪个确切版本。

但任何人都能为替换后的文件计算并公布新摘要。如果不可信来源同时控制下载内容和比较值，两者一致并不能让来源更可信。我们用两个无害单字节消息展示这个有限事实：摘要彼此不同，而每个消息都与为它自己重新计算的摘要匹配。

比较对象必须是确切的文件。压缩包、解压文件和重新打包的档案，即使包含相似材料，字节也会不同。应核对发布者说明指定的对象。随手换一个方便的对象去算哈希，结果不同并不能单独证明篡改，也可能只是比较错了东西。

签名增加了什么证据

在公钥签名方案中，签名使用私钥，验证使用对应公钥。在算法假设成立的范围内，验证成功支持关于这些精确字节和该密钥的一项判断。验证者不需要得到私有签名密钥，因此签名适合用于公开软件分发。

公钥仍须与目标发布者建立可信联系。在任意密钥下得到有效签名，不等于核验身份。签名也不加密消息：若文件本来可读，持有者依然可以读取。真实性、保密性和实用性仍是不同属性。

公钥与发布者的关联，必须有裸验证结果之外的依据。只随陌生文件一起提供的公钥，不能独立证明这种关联。成熟软件分发体系的受支持工具可以管理信任关系。按其文档流程操作，不要仅为让警告消失，就手动接受新公钥。

只验证，不创建凭证

实际本地检查使用 RFC 8032 中 Ed25519 向量的 TEST 2。消息只有一个字节，十六进制为 72。我们只把公开的 32 字节公钥和 64 字节签名载入已安装的 cryptography 库，没有生成凭证、载入私钥或创建新签名。

公开消息验证成功。把消息字节改为十六进制 73 后，验证被拒绝。恢复原消息，但翻转签名的一个比特，也被拒绝。这些是验证接口的实际结果，不代表我们测试了登录系统、保护了下载服务，或认证了真实机构。

参照值从哪里来

验证真实软件时，应遵循发布者说明，在适当情况下使用成熟安装器、包管理器或操作系统信任机制。关键问题是：预期公钥或摘要如何来到你手中？陌生页面把公钥摆在文件旁边，并不能独立证明公钥属于谁。

密钥可能更换、撤销或泄露。有意义的验证流程可能需要最新信任信息与正确发布背景，而不只是数学检查亮绿灯。本次公开标准样本有意不处理这些运营问题。它的价值在于可复现，局限则是测试密钥并不代表任何可信软件发布者。

设想官方发布页、聊天中转来的文件，以及同一聊天提供的校验和。文件和校验和一致，可能只说明发送者给了一对自洽材料，并不继承官方页面的权威。应独立进入发布者渠道，确认产品、版本和平台，再判断哪个参照值或签名身份适用。

签名有效，文件仍可能不合适

正确签名的程序仍可能有缺陷、执行你不希望的行为，或请求不该授予的权限。签名帮助确认密钥关系，不是审查所有可能行为。同样，签名正确的旧版本可以确实来自发布者，却缺少新受支持版本已有的修复。

注意具体文件、目标平台、版本信息和来源。不要因为页面写着“已签名”就绕过警告。若验证失败，应停止，通过发布者的已知渠道核查，而不是把失败当成碍事的步骤。检查成功，与有充分理由运行软件，相关却不相同。

保留文件与运行文件，是不同决定。验证成功可以支持来源判断，却没有回答是否需要、权限是否适当、是否兼容。验证失败则应暂停操作并调查，而不是关闭检查直到能运行。通过发布者支持渠道解决不匹配，不把每次失败都当成某种具体攻击的证据。

多一个换行，也会改变被签名的对象

沿用公开 RFC 测试向量，在单字节消息后加一个换行字节，验证拒绝两字节版本；加回车与换行后得到三字节版本，也被拒绝。原单字节仍通过，三份 SHA-256 摘要各不相同。这只是小幅字节变化，不是在评价真实下载文档的外观。

接着保留原消息和签名，换成另一个公开 RFC 测试向量的公钥，验证失败。这个负向对照说明，不是随便提供一把看起来有效的公钥就能通过。没有生成新密钥或签名；两把公开测试钥匙都只是教学样本，不代表软件发布者身份。

普通读者不必处理十六进制，也能应用这个区别：按官方步骤核验时保留下载的原文件，不要在检查前把已签名文本打开重存。工具报告不匹配时，从可信来源核对指定文件和发布信息。拒绝说明检查失败，本身不说明原因。

不必自己发明协议

普通读者最有用的技能，是分清手里有哪些证据。校验和是与参照比较，签名增加密钥关系，可信分发渠道为密钥提供更多背景，而软件目的和权限仍值得留意。陌生徽章不应替代这些检查。

应使用受支持的验证工具，不要把一段短小密码学示例复制成新的安全系统。本次代码刻意限于公开样本和少量反向检查。实验能得出的精确结论很小：在指定公开测试密钥下，改变签名消息或该签名，都会使验证失败。