---
title: "密码学哈希函数"
description: "一份以验证为重点的密码学哈希函数指南，涵盖安全属性、字节编码、SHA-2、SHA-3、Keccak、区块链用途与实现风险。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 密码学哈希函数

> 仅供教育用途，不构成投资或密码学实现建议。摘要相符本身并不能证明真实性、所有权、授权、最终性或数据可用性。

<a id="answer"></a>

## 直接答案

密码学哈希函数以确定性的方式，将以字节表示的消息映射为具有规定输出长度的摘要。对于输出长度固定为 `n` 位的哈希函数，基本关系为：

`h = H(m), where h is in {0,1}^n`

相同的字节和算法会产生相同的摘要。输入改变一位，应当会以不可预测的方式改变许多输出位，但这种雪崩效应并不是安全性的定义。主要安全目标是**原像抗性**（给定一个摘要，找到能产生该摘要的输入在计算上不可行）、**第二原像抗性**（给定一个输入，找到与它摘要相同的另一个输入在计算上不可行）和**碰撞抗性**（找到摘要相同的任意两个不同输入在计算上不可行）。

哈希不是加密：它没有解密密钥，也不保证可以恢复输入。由于无限多个可能的消息会被映射到有限的输出空间，碰撞必然存在；安全性意味着，对于所选算法和输出长度，找到可利用的碰撞在计算上不可行。

摘要本身也不提供真实性保证。只有预期摘要和算法通过可信渠道取得时，重新计算文件哈希才能据此发现不一致。协议会将哈希与签名、消息认证码、认证数据结构、共识规则或工作量证明结合起来，从而获得更强的保证。

<a id="mechanism"></a>

## 工作原理

1. **明确确切的字节。** 文本编码、大小写、空白、字段顺序、整数表示、长度前缀和序列化方式都会影响 `m`。协议必须规定规范编码，并将哈希绑定到特定的算法、版本、网络和用途。
2. **执行指定的构造。** SHA-256 会对长度受限的消息进行预处理，将其分块，并迭代更新内部状态。SHA3-256 使用基于 KECCAK 的海绵构造。两者都返回 256 位摘要，但它们是不同的函数，输出不能互换。
3. **按所需属性理解安全性。** 对于理想的 `n` 位哈希函数，通用原像搜索大约需要 `2^n` 次计算，而由于生日效应，通用碰撞搜索大约需要 `2^(n/2)` 次计算。如果算法已被攻破、摘要遭到截断或外围协议存在缺陷，仅看输出长度并不足以判断安全性。
4. **围绕摘要构建协议。** 数字签名方案可以对消息的摘要签名；HMAC 加入密钥来实现消息认证；默克尔树用一个根对许多叶节点作出承诺；工作量证明则反复对候选区块头进行哈希，直到摘要满足目标值。这些构造提供的保证各不相同。
5. **使用区块链指定的确切函数。** 比特币区块头和默克尔节点按规定的字节顺序使用双重 SHA-256。以太坊执行层使用标准化前 KECCAK 设计中的 Keccak-256，而不是标准化的 SHA3-256。因此，“256 位哈希”这样的标签不足以用于验证。
6. **先验证上下文，再解读含义。** 检查预期摘要的来源、算法标识符、字节编码、域或区块链、所引用的区块和状态、确认状态以及是否存在截断。在错误的上下文中计算正确，验证仍然失败。

<a id="example"></a>

## 示例详解

- **输入的微小变化。** 五个 UTF-8 字节 `hello` 的 SHA-256 是 `2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824`。将第一个字节替换为大写 `H` 后，结果是 `185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969`。摘要不同并不会透露究竟是哪个字节发生了变化。
- **在不同攻击模型中，安全强度不一定等于摘要长度。** 理想的 256 位哈希函数提供的原像搜索工作量约为 `2^256`，碰撞搜索工作量则为 `2^128`。当协议依赖碰撞抗性时，这一区别十分重要，数字签名流程通常就是如此。
- **默克尔证明只针对某一个根来认证包含关系。** 验证者按规定顺序，将经过编码的叶节点与提供的每个兄弟节点一起进行哈希，直到重建出被承诺的根。结果相符并不能证明该根已经最终确定、叶节点数据真实，或未被提供的数据仍然可用。
- **工作量证明增加了目标值规则。** 只有当候选区块头的双重 SHA-256 值按照共识规则解读后小于或等于编码后的目标值时，比特币才会验证通过。矿工付出更多工作，并不会让摘要具有更强的碰撞抗性。

<a id="risks"></a>

## 风险

- 使用已弃用或不适用的算法，尤其是在需要碰撞抗性时仍依赖 SHA-1。
- 将 SHA3-256、Keccak-256、SHA-256、双重 SHA-256 以及截断方式不同的变体视为可互换。
- 对显示出来的文本而非规范字节进行哈希，或忽略 Unicode 规范化、空白、字节序、字段顺序和长度编码。
- 从同一个已遭入侵的位置下载文件及其预期摘要，因而无法得到独立的完整性检查。
- 使用快速的通用哈希函数直接存储密码，而不是采用带盐、专门用于密码哈希且工作因子适当的方案。
- 使用 `H(secret || message)` 自制认证码；某些迭代式哈希构造容易受到长度扩展攻击，而 HMAC 是专为密钥认证设计的。
- 截断摘要时，没有根据协议的规模和威胁模型计算截断后的碰撞安全性与原像安全性。
- 在不同协议中重复使用一种编码而不做域分离，使得在一个上下文中有效的摘要可能被解释到另一个上下文中。
- 认为交易哈希能够证明确认、最终性、执行成功、所有权或区块链不会重组。
- 认为内容哈希能保证取回所引用的数据；即使所有可用副本都已消失，承诺仍可能有效。
- 比较区块浏览器显示的字符串时，不检查字节序、前缀规则、序列化方式，或界面是否以不同形式显示内部标识符。
- 在缺少标准测试向量、持续维护的库、独立审查和升级流程的情况下实现密码学原语。

<a id="misconceptions"></a>

## 常见误区

- **哈希就是经过加密的数据。** 加密可以使用正确的密钥逆转；密码学哈希是单向摘要，不存在解密操作。
- **不同输入绝不可能具有相同摘要。** 固定长度的输出必然存在碰撞。安全的设计会让寻找和利用碰撞在计算上不可行。
- **256 位摘要始终提供 256 位安全强度。** 对于理想的 256 位哈希函数，通用碰撞抗性约为 128 位，协议选择还可能进一步降低这一强度。
- **哈希相符就能证明消息由谁创建。** 单独的哈希不含秘密，也不认证发送者；当来源很重要时，应使用签名或适当的 MAC。
- **Keccak-256 和 SHA3-256 是同一个函数的两个名称。** 它们采用密切相关的设计，但标准化参数不同，生成的摘要也不同。
- **链上交易哈希能够证明结算。** 它标识经过编码的交易数据；区块链收录、执行状态、确认和最终性是彼此独立的事实。

<a id="related"></a>

## 相关主题

- [区块链](/zh-cn/crypto/blockchain/)
- [区块链不可能三角](/zh-cn/crypto/blockchain-trilemma/)
- [默克尔树](/zh-cn/crypto/merkle-tree/)
- [工作量证明](/zh-cn/crypto/proof-of-work/)

<a id="sources"></a>

## 来源

- [哈希函数](https://csrc.nist.gov/projects/hash-functions) - NIST（查阅日期：2026-08-20）
- [安全哈希标准（SHS）](https://doi.org/10.6028/NIST.FIPS.180-4) - NIST（查阅日期：2026-08-20）
- [SHA-3 标准：基于置换的哈希与可扩展输出函数](https://doi.org/10.6028/NIST.FIPS.202) - NIST（查阅日期：2026-08-20）
- [比特币开发者参考：区块链](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin.org（查阅日期：2026-08-20）
- [以太坊黄皮书](https://ethereum.github.io/yellowpaper/paper.pdf) - Ethereum（查阅日期：2026-08-20）

Source: https://wiki.fcontext.com/zh-cn/crypto/cryptographic-hash/index.mdx