SHA-1 哈希生成器（160 位遗留算法）

什么是 SHA-1？

// Hash text using Web Crypto API (SHA-1 — legacy use only)
async function sha1(text) {
  const data = new TextEncoder().encode(text);
  const hash = await crypto.subtle.digest('SHA-1', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

await sha1('Hello, World!');
// → '0a0a9f2a6772942557ab5355d76af442f8f65e01'
// ⚠️ SHA-1 is broken — use SHA-256 for new work.

SHA-1 示例

tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author A Dev <dev@example.com> 1716854400 +0000
committer A Dev <dev@example.com> 1716854400 +0000

Initial commit

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKlL...
-----END CERTIFICATE-----

node-v0.12.7-linux-x64.tar.gz

（通过「文件」选项卡粘贴 Google/CWI shattered-1.pdf 文件内容）

如何生成 SHA-1 哈希值

1. 1

   粘贴文本或拖入文件

   选择「文本」选项卡，粘贴任意字符串——提交消息、证书正文或遗留校验和输入——到输入区域。SHA-1 哈希值会随输入实时更新。对于文件，切换到「文件」选项卡，将任意文件拖入拖放区；浏览器在本地对其进行哈希，无需上传。

2. 2

   复制 40 字符哈希值

   点击哈希输出旁的「复制」按钮。完整的 40 字符小写十六进制字符串将复制到剪贴板。如果你的遗留系统需要大写十六进制，可使用「大写」切换——部分旧工具和 Windows API 默认使用大写。

3. 3

   与遗留指纹进行比对

   切换到「对比」选项卡，并排粘贴两个 SHA-1 哈希值以确认是否一致。适用于核验遗留发布方的校验和、审计镜像 Git 仓库，或核查早于 SHA-256 普及时代的文档中的旧版 TLS 证书指纹。

技术细节

算法：Merkle-Damgård 构造，80 轮

SHA-1 以 512 位（64 字节）块处理输入，分四个各 20 轮的阶段应用 80 轮位运算，每阶段使用不同的逻辑函数（Ch、Parity、Maj、Parity）和从小整数平方根派生的加法常数。初始哈希状态为五个 32 位字（A–E），最终哈希是最后一个块处理后这些字的拼接。实现定义于 FIPS 180-1（1995 年），由 FIPS 180-4（2015 年）取代，后者正式包含弃用语言。

输出：160 位，40 个十六进制字符

始终恰好为 40 个小写十六进制字符（160 位 = 20 字节，每字节编码为 2 个十六进制字符）。无论输入大小，输出长度固定。与 SHA-256 的 64 字符相比，更短的输出提供了更少的碰撞阻力位数——这是 SHA-1 早于 SHA-256 被破解的关键因素。

性能：快速，但这正是问题所在

SHA-1 运算速度很快——在浏览器中使用 Web Crypto 通常可达 400–700 MB/s，与 SHA-256 相当。对于攻击者而言，这种速度是一种优势：现代 GPU 集群每秒可计算数十亿个 SHA-1 哈希值，加速了暴力破解和碰撞搜索。正是因为速度快，SHA-1（如 MD5）绝不能用于密码存储——请改用 bcrypt、scrypt 或 Argon2。

标准：FIPS 180-1（1995 年）——在 FIPS 180-4 语境下已弃用

SHA-1 在 FIPS 180-1（1995 年）中标准化，取代了有缺陷的 SHA-0。NIST 于 NIST SP 800-131A（2011 年）中将 SHA-1 用于数字签名的场景标记为弃用，并在 FIPS 186-5（2023 年）中正式禁止其用于所有数字签名生成。RFC 6194（2011 年）记录了已知安全注意事项。W3C WebCrypto API 出于遗留互操作性原因仍包含 SHA-1，这正是本浏览器工具能够计算它的原因。

最佳实践

切勿将 SHA-1 用于安全敏感操作

SHA-1 在数字签名、TLS 证书、代码签名、密码存储以及任何需要碰撞阻力的工作流中均已被弃用。2017 年的 SHAttered 攻击证明了实际碰撞的可行性。对于所有安全用途，请迁移到 SHA-256 或 SHA-3。在现代硬件上，成本差异可以忽略不计——SHA-256 在所有现代 CPU 和 GPU 上均有硬件加速支持。

SHA-1 用于遗留指纹查询是可接受的

如果你需要核验 2017 年前的文件校验和、查询 Git 提交 ID，或出于审计目的检查旧证书指纹，SHA-1 是合适的。哈希本身并不用于做出信任决策——你只是为了交叉参考而重现一个已知的指纹。在审计日志中明确记录这一点：「SHA-1 仅用于遗留参考，不用于安全验证。」

始终对 UTF-8 字节而非 Unicode 码位进行哈希

SHA-1 与所有哈希算法一样，操作字节而非字符。同一字符串以 UTF-8 和 UTF-16 编码会产生不同的哈希值。本工具在哈希前始终将输入编码为不含 BOM 的 UTF-8。如果你需要匹配使用不同编码（Windows UTF-16-LE、Latin-1）的系统，必须在外部预先编码输入后再比较哈希值。

在代码中验证哈希值时使用恒定时间比较

如果在代码中比较两个 SHA-1 哈希值，请使用恒定时间等值检查——Node.js 的 crypto.timingSafeEqual()、Python 的 hmac.compare_digest()——而非简单的字符串等值比较（=== 或 ==）。简单比较会泄漏时序信息，理论上允许攻击者逐字节重建预期哈希值。即使对于遗留 SHA-1 验证，这也是一种纵深防御措施。

SHA-1 常见问题