SHA 哈希算法完整指南

SHA（Secure Hash Algorithm，安全散列算法）是由美国国家安全局（NSA）设计、美国国家标准与技术研究院（NIST）发布的一系列密码学哈希函数标准。它将任意长度的输入数据映射为固定长度的散列值（摘要），并具有两大核心特性：单向不可逆（无法从散列值反推原始内容）和雪崩效应（输入的微小变化导致输出截然不同）。

SHA 家族主要分为两代：

• SHA-1（160 位）：1995 年发布，输出 40 个十六进制字符，一度被广泛用于数字证书与 Git 提交中，但在 2017 年因碰撞攻击被正式废弃。
• SHA-2（224/256/384/512 位）：2001 年发布的第二代标准，包含 SHA-224、SHA-256、SHA-384、SHA-512 四种输出长度。其中 SHA-256（64 个十六进制字符）与 SHA-512（128 个十六进制字符）是当前业界事实上的默认选择。
• SHA-3：2015 年发布的第三代标准，采用 Keccak 结构，与前两代的 Merkle-Damgård 结构完全不同，主要用于政府与极高安全需求场景。

从 TLS 证书签名、SSH 指纹、Git 提交、Bitcoin 区块头、到常见软件下载完整性校验，SHA-256 几乎无处不在。使用 我们的在线 SHA 工具，您可以在同一界面中对比 SHA-1、SHA-256、SHA-384、SHA-512 的输出差异。

尽管 SHA-1 与 SHA-2 在名称上属于同一家族，它们之间的设计差异直接决定了各自的安全边界。两者均基于 Merkle-Damgård 结构（将输入按固定大小分块，循环压缩），但内部运算设计不同：

• 消息填充与分块：输入消息在末尾追加 0x80，填充 0 直到长度模 512 位（或 SHA-512 的 1024 位）等于特定值，最后 64/128 位记录原始消息长度。
• SHA-1 的内部运算：每个 512 位分块被拆为 16 个 32 位字，扩展为 80 轮。每轮交替使用 4 个非线性函数（Ch/Maj/Parity），配合 5 个状态寄存器与固定常数，最终产生 160 位输出。
• SHA-256 的内部运算：同样使用 512 位分块，但扩展到 64 轮，引入了 Σ/σ + Ch/Maj 等更复杂的位运算和 64 个独立常数，输出 256 位。SHA-512 采用 1024 位分块，80 轮运算，内部为 64 位字，输出 512 位。

输出长度差异直观可见：

• SHA-1：40 个 hex 字符（160 位）
• SHA-256：64 个 hex 字符（256 位）
• SHA-384：96 个 hex 字符（384 位）
• SHA-512：128 个 hex 字符（512 位）

在 我们的 SHA 工具 中，只需在下拉菜单中切换算法，即可看到相同输入对应的不同输出长度与字符差异。

SHA 输出的本质是固定长度的二进制字节数组。实际开发中，通常以以下 3 种可打印格式传递：

• 十六进制小写：每个字节表示为 2 个小写十六进制字符（0-9、a-f），是最通用的默认格式。sha256sum、openssl dgst -sha256、Git、Docker 等都默认输出小写。
• 十六进制大写：内容与小写完全相同，仅以大写字符（A-F）呈现。某些 Windows API、旧协议、数据库系统可能要求大写。字符串等价但数值不同，直接比对会失败。
• Base64 编码：对原始二进制散列值做 Base64 编码，得到更紧凑的可打印字符串（SHA-256 为 44 字符），适合嵌入 URL 参数、JWT 头、HTTP 请求签名、JSON 配置等。

跨系统对接时最常见的陷阱就是"大小写不一致"。如果 A 系统以小写十六进制存储，B 系统以大写校验，字符串相等判断会直接失败，尽管数值相同。

我们的工具在一次输入后同时提供小写、大写与 Base64 三种输出，无需手动转换，避免此类低级错误。

SHA 家族的使用场景几乎覆盖所有涉及"完整性"与"不可否认性"的系统。以下是 7 个最典型的真实使用场景：

• TLS/SSL 数字证书签名：网站证书中使用 SHA-256/SHA-384 作为签名算法（旧证书可能仍用 SHA-1，已被浏览器标红）。
• 软件下载完整性校验：Linux 发行版 ISO、开源软件安装包通常提供 SHA256SUMS 文件，用于验证下载镜像未被篡改。
• Git 提交与对象标识：Git 用 SHA-1（现正在迁移到 SHA-256）为每次提交、文件、树对象生成唯一标识，分布式工作流的核心基石。
• 区块链与加密货币：Bitcoin 使用双 SHA-256 进行工作量证明与地址派生，Ethereum 使用 Keccak-256（类 SHA-3）。
• 密码存储（带盐）：历史上许多系统使用 SHA-256(salt + password) 存储密码。注意：现代推荐使用 bcrypt/scrypt/Argon2 等专用 KDF，而非裸 SHA。
• API 请求签名：在 OAuth、HMAC-SHA256、AWS 签名 v4 等协议中，SHA-256 作为摘要函数参与计算请求签名，防止中间人篡改。
• 文件去重 / 缓存键：在备份系统、对象存储、CDN 缓存中，SHA-256 被用作文件内容的指纹以实现"内容寻址"与去重。

在上述前 6 个场景中，应严格使用 SHA-2 系列（SHA-1 已不推荐）。最后一个场景则对算法选择更宽松，追求性能优先。我们的在线工具可快速验证上述所有场景的散列值。

理解不同哈希方案的差异能让您在架构决策时做出正确选择。下表给出常用方案在速度、安全性与适用场景方面的直观对比：

• MD5（128 位，速度极快）：仅适用于文件去重、缓存键、非安全场景的校验。密码学上已被破解，不可用于签名或密码存储。
• SHA-1（160 位，中等速度）：碰撞攻击已证明。保留使用仅限于只读旧系统与向后兼容，新系统不应选择。
• SHA-256 / SHA-512（256/512 位，较慢但安全）：当前通用首选。用于证书、API 签名、文件完整性、区块链等绝大多数安全场景。
• HMAC-SHA256：将密钥与消息组合后再做 SHA-256，用于消息认证与 API 签名。带有密钥，可防止无密钥的攻击者伪造。
• bcrypt / scrypt / Argon2 / PBKDF2：慢速、可配置迭代次数的密钥派生函数，专门用于存储用户密码，抵制 GPU 暴力破解。

经验法则：普通完整性校验选 SHA-256；需要密钥认证选 HMAC-SHA256；存储用户密码选 bcrypt/Argon2；仅追求性能且不涉及安全时可选 MD5 或 xxHash。

在 我们的工具中，一次输入可同时比较 4 种 SHA 变体，帮助您快速理解算法差异。

在日常开发中，SHA 的使用看似简单，实则有不少容易忽略的细节。以下是 6 条实用技巧：

• 统一十六进制大小写约定：团队内部统一使用小写（推荐）或大写，在 API 边界强制统一，避免字符串相等判断失败。
• 对比时进行标准化：从外部系统（用户输入、第三方 API）读取的散列值，先做 toLowerCase() 与空白符清理再比对。
• 注意字符编码问题：同一字符串在 UTF-8、UTF-16、GBK 编码下得到的 SHA 值完全不同。跨语言/跨平台时务必统一为 UTF-8。
• 不要用裸 SHA 存储密码：对密码请使用 bcrypt/Argon2，它们内置盐值与迭代次数，可抵御 GPU 暴力破解。
• 需要认证时用 HMAC：如果不仅要验证完整性，还要证明消息来自受信方，请用 HMAC-SHA256（带密钥）而非裸 SHA。
• 用在线工具快速验证：在调试签名失败、API 联调时，使用 本地处理的在线工具粘贴原始字符串快速比对，比编写临时脚本或打开终端更快。

这些技巧覆盖了 90% 以上 SHA 相关的"小坑"。将它们写入团队规范或 Code Review 清单，可以显著减少联调时间。

当您需要计算 API 密钥、密码、内部文档片段等敏感数据的散列值时，选择"看似方便"的在线工具可能带来意想不到的风险。关键问题是：该工具是否将您的输入发送到了服务器？是否会写入日志？

我们的 SHA 计算工具基于浏览器内置的 Web Crypto API（crypto.subtle.digest）实现。所有运算完全发生在您的浏览器中，HTTP 层面不存在任何与计算相关的上传或下载请求，也不会将您的输入写入 localStorage 或 Cookie。

即使如此，以下是一些额外的安全建议：

• 处理极敏感内容时使用隐私浏览模式：这样关闭窗口后不会在浏览器历史、自动填充或扩展中留下痕迹。
• 不要在公共设备或公司监控设备上输入密钥：键盘记录器与屏幕录制可能绕过浏览器层的安全保护。
• 存储用户密码务必使用 KDF：SHA 是快速哈希，无法对抗 GPU 集群的暴力破解。对密码请使用 bcrypt/scrypt/Argon2。
• 传输散列值不等于传输原始内容：散列值可以公开分享，但原始敏感信息绝不可以。

选择 一个本地处理、无日志、无上传的在线工具，可以在不牺牲便利性的同时，牢牢掌握自己的数据控制权。