哪些系统在悄悄用 SHA256 - 极速工具箱

SHA-256 是一个「看不见的基础设施」——绝大多数用户一辈子不会主动计算一次 SHA-256，但它每天都在为他们的每一次 HTTPS 访问、每一次代码下载、每一次登录提供保护。了解一下它出现在哪些地方，能帮你在遇到相关问题时知道该往哪里找。

传输层：TLS 证书签名

打开浏览器访问一个 HTTPS 网站，握手过程中会验证服务器证书的签名。这个签名用的就是哈希加签名的组合，而现代证书的哈希算法基本都是 SHA-256。

回顾一下历史能看清趋势：早期证书用 MD5，MD5 被攻破后换成 SHA-1，SHA-1 在 2017 年被实际碰撞后，主流 CA 全面转向 SHA-256。每一次迁移都是由上一个算法的失守推动的。这也解释了为什么证书领域对新算法的采用相对保守——迁移成本太高，只能等旧算法真正不能用了再动。

操作系统和应用的安装包通常带有数字签名，用来证明「这个包来自声称的发布者，且没有被改动」。签名算法同样基于哈希，主流选择是 SHA-256。

固件领域更依赖这个机制。设备启动时会先校验固件的哈希与签名，只有验证通过才加载。这是安全启动（Secure Boot）的基础，也是防止恶意固件植入的关键环节。在这类场景里，哈希的碰撞抗性是硬要求，SHA-1 和 MD5 都不能用。

JSON Web Token 的签名算法里有 HS256 和 RS256 两种常见取值，其中的「256」指的就是 SHA-256。HS256 是 HMAC-SHA256，用对称密钥；RS256 是 RSA-SHA256，用非对称密钥。

选型上，单服务场景用 HS256 就够了，密钥不出服务边界；如果签发方和验证方是不同系统，或者需要让第三方独立验证 token 而拿不到密钥，就要用 RS256。

开放平台的接口签名也大量使用 HMAC-SHA256，逻辑与前面讲 HMAC 时一致：用密钥保证只有持有者能生成合法签名。

比特币的工作量证明用的是双重 SHA-256——把 SHA-256 的结果再哈希一次。矿机围绕这个算法做了高度专用的 ASIC 优化，这也是为什么比特币的算力可以用「每秒多少次哈希」来衡量。

这个案例说明了一件事：算法的确定性是共识机制的前提。所有节点必须对同一份数据算出完全相同的结果，不能有任何随机性或平台差异。哈希函数天然满足这个要求，而且验证成本极低——算出答案很难，验证答案只要一次计算。

用内容的哈希作为标识，可以天然实现去重和一致性校验。容器镜像的每一层、内容分发网络的缓存键、备份系统的块级去重，背后都是这个思路。

这一层的价值在于「同样的标识必然是同样的内容」。如果算法被攻破，攻击者可以构造两个内容不同但标识相同的对象，从而污染存储或者绕过缓存校验。所以这一层同样建议使用 SHA-256 而非 MD5。

把上面这些场景放在一起看，会发现它们有一个共同要求：结果必须稳定且可复现。

同一个输入，无论在哪台机器、哪个时间、哪个语言实现上计算，都必须得到完全相同的输出。没有随机性，没有平台依赖，没有版本差异。这个性质是哈希函数能成为基础设施的根本原因——它让不同系统之间可以只交换摘要，就完成对内容的确认。