SipHash 哈希函数：从非对抗环境到对抗环境的密码学演进

密码学概念 · 2026-09-08

概述

传统密码学哈希函数（如 MD5、SHA-1、SHA-2、SHA-3）的安全性建立在对抗环境不可行的假设上——攻击者需要在计算上难以找到碰撞或预图像。然而，这些哈希函数应用于哈希表时存在一个根本性缺陷：当哈希函数被固定且可预测时，攻击者可以构造精心设计的输入导致哈希碰撞，使哈希表退化为链表或树结构，造成 O(n) 时间复杂度。

这就是著名的 哈希洪水攻击（Hash Flooding Attack），首次由 Per Lundqvist 等人在 2003 年提出，并被用于破坏 Perl、PHP、Ruby 等语言的哈希表实现。该攻击的核心思想是：利用已知哈希算法的结构弱点，生成大量碰撞输入，耗尽服务器 CPU 资源。

SipHash 是应对这一威胁的解决方案。它由 Daniel J. Bernstein（丹尼斯·伯恩斯斯坦）和 Niels Duif 于 2014 年设计，基于 ChaCha 流密码的核心结构，提供抗碰撞的哈希表密钥派生功能。SipHash 的安全性不依赖于计算复杂度，而是通过引入秘密密钥，使攻击者无法预先构造碰撞输入。

SipHash 的设计动机

哈希表的安全困境

现代编程语言广泛使用哈希表作为核心数据结构。以 Python 为例，字典（dict）内部使用基于 MurmurHash 的混合哈希函数；Java 的 HashMap 默认使用 HashMap.hash() 方法。这些哈希函数的设计目标是速度和均匀分布，而非抗碰撞安全性。

问题在于：当攻击者知道哈希函数的具体实现时，可以：

枚举可能的哈希值范围（如 32 位或 64 位）
反向推导产生目标哈希值的输入
构造大量碰撞输入，触发哈希冲突

这种攻击在 Web 应用中尤为危险——攻击者可以通过 HTTP 请求发送精心构造的 JSON 对象或表单数据，导致服务端哈希表膨胀，引发拒绝服务（DoS）。

2011-2014 年的安全事件

2011 年：Per Lundqvist 等人发表《SoK: Secure Hash Functions》，系统分析哈希表的攻击向量
2012 年：Facebook 遭遇大规模哈希洪水攻击，攻击者利用 Ruby on Rails 的哈希实现漏洞
2014 年：Rust 社区发起 SipHash 标准化工作，最终成为标准库默认哈希函数
2015 年：Python 3.4.4 开始引入 SipHash 作为字符串哈希函数

这些事件促使密码学界重新审视哈希函数的安全属性，推动了从计算安全到信息论安全的转变。

SipHash 的数学结构

ChaCha 核心：SipHash 的基础

SipHash 的核心是 ChaCha 压缩函数，这是一种基于 ARX（Add-Rotate-XOR）操作的流密码结构。ChaCha20 的核心操作定义为：

CODE

QuarterRound(a, b, c, d):
     a += b; d ^= a; d <<= 16;
     c += d; b ^= c; b <<= 12;
     a += b; d ^= a; d >>= 8;
     c += d; b ^= c; b >>= 7;

其中 += 表示模 2^32 加法，^= 表示异或，<<= 和 >>= 表示循环移位。

ChaCha 的安全性保证：

每个 QuarterRound 操作都是双射（bijection），确保输出分布均匀
旋转量（16, 12, 8, 7）的选择经过严格分析，确保快速扩散（avalanche effect）
8 轮 ChaCha 压缩后，输出与输入之间没有任何可预测的线性或差分关系

SipHash 完整算法

SipHash 使用 ChaCha20 的 4 轮压缩作为核心，定义如下：

CODE

SipHash(message, key):
     // 初始化状态
     v0 = 0x736f6d6570736575  // "somepsec"
     v1 = 0x646f72616e646f6d  // "drandmo"
     v2 = 0x6c7967656e657261  // "lygfera"
     v3 = 0x7465646279746573  // "tedbytes"
     
     // 注入密钥
     v0 ^= key[0:8]
     v1 ^= key[8:16]
     v2 ^= key[0:8]
     v3 ^= key[8:16]
     
     // 消息处理（按 8 字节块）
     for each block m of message:
         v3 ^= m
         compress(v0, v1, v2, v3)  // 4 轮 ChaCha
         v0 ^= m
     
     // 处理最后一个不完整块
     v3 ^= last_byte_of_message
     compress(v0, v1, v2, v3)
     
     // 最终混合
     v0 ^= 0xff
     compress(v0, v1, v2, v3)
     v1 ^= 0xff
     compress(v0, v1, v2, v3)
     v2 ^= 0xff
     compress(v0, v1, v2, v3)
     v3 ^= 0xff
     compress(v0, v1, v2, v3)
     
     return v0 || v1 || v2 || v3

SipHash-2-4 参数含义

SipHash 有四个参数版本：

变体	压缩轮数	初始轮数	输出长度	适用场景
SipHash-2-4	2	4	64 位	通用哈希表（默认）
SipHash-3-4	3	4	64 位	高安全需求
SipHash-4-4	4	4	64 位	最高安全需求
SipHash-1-4	1	4	64 位	性能优先

命名规则：第一个数字表示主循环中的压缩轮数（c），第二个数字表示初始和最终的压缩轮数（d）。

SipHash-2-4 是最常用的版本，压缩轮数为 2+4+4=10 轮，提供了良好的安全性和性能平衡。

SipHash 的安全性分析

密码学安全属性

SipHash 的安全性基于以下假设：

密钥隐藏：攻击者不知道密钥 k，无法构造碰撞输入
ChaCha 的伪随机性：压缩函数产生的输出与随机函数不可区分
扩散特性：每个输入位影响所有输出位（雪崩效应）

安全性证明

SipHash 的安全性证明采用了不可区分性（indistinguishability）模型：

定理：SipHash-2-4 在随机置换 oracle 模型下，对于任意多项式时间攻击者 A，存在一个可忽略函数 ε(n)，使得：

CODE

Pr[A distinguishes SipHash from random function] ≤ ε(n)

证明思路：

ChaCha 的 8 轮压缩（4 轮初始 + 4 轮主循环）已被证明是强伪随机置换（PRP）
SipHash 的密钥注入步骤将密钥与初始化向量结合，确保不同密钥产生不同的哈希函数族
最终混合步骤确保输出分布均匀，无统计偏差

与 MAC 的关系

SipHash 本质上是一个带密钥的哈希函数（Keyed Hash Function），其结构与 HMAC 类似：

CODE

HMAC-K(M) = H((K ⊕ opad) || H((K ⊕ ipad) || M))
 SipHash_K(M) = Compress(Initial(K, M))

区别在于：

HMAC 需要两次哈希运算，SipHash 只需要一次
SipHash 的输出长度固定为 64 位，HMAC 可以使用任意哈希函数
SipHash 专门针对短消息（< 256 字节）优化，HMAC 适用于任意长度消息

SipHash 的工程实践

Rust 标准库的默认哈希函数

Rust 从 1.7 版本开始将 SipHash-2-4 作为标准库默认的哈希函数：

RUST

use std::collections::HashMap;
 
 fn main() {
     let mut map = HashMap::new();
     map.insert("key".to_string(), 42);
     
     // 内部使用 SipHasher 作为默认哈希器
     println!("Value: {}", map.get("key").unwrap());
 }

为什么 Rust 选择 SipHash？

防 DoS 攻击：即使攻击者知道哈希算法，也无法构造碰撞输入
性能可接受：SipHash-2-4 在 64 位处理器上约 0.5-1 ns/字节
实现简洁：仅依赖 ARX 操作，无需查表

Python 的实现

Python 3.4+ 使用 SipHash 作为字符串哈希函数：

PYTHON

# Python 内部实现（简化版）
 def siphash(data: bytes, key: bytes) -> int:
     # 使用 SipHash-2-4 算法
     # 返回 64 位哈希值
     pass

注意：Python 的 hash() 函数对字符串使用 SipHash，但对整数使用恒等映射（hash(n) = n），因此整数字典仍然可能受到碰撞攻击。

C/C++ 实现

参考实现在 IETF draft-irtf-cfrg-siphash 的附录中提供C语言参考实现：

#include <stdint.h>
extern uint64_t siphash24(const uint8_t *in, const size_t inlen, const uint8_t *k);

性能基准（基于 x86_64 @ 3.0 GHz，Intel Ice Lake）：

操作	时间	吞吐量
SipHash-2-4 (64 字节)	约 50 ns	约 1.2 GB/s
SipHash-2-4 (1024 字节)	约 500 ns	约 2.0 GB/s
MurmurHash3 (64 字节)	约 10 ns	约 6.0 GB/s
MurmurHash3 (1024 字节)	约 80 ns	约 12.5 GB/s

注意：以上性能数据来源于学术文献测试，实际性能因实现和优化而异。

性能对比结论：SipHash 比 MurmurHash 慢约 5-10 倍，但提供了更强的安全性保障。对于哈希表应用，这种性能代价是可接受的。

Go 语言的实现

Go 从 1.5 版本开始使用 SipHash 作为 map 的默认哈希函数：

package main

import "fmt"

func main() {
    m := make(map[string]int)
    m["key"] = 42
    
    // 内部使用 siphash24 作为默认哈希器
    fmt.Println(m["key"])
}

Go 的优化：Go 使用了 SipHash-2-4 的变体，通过 SIMD 指令（AVX2）进一步优化性能。

SipHash 与国密算法的对比

与 SM3 的对比

SM3 是中国国家标准化的密码杂凑算法（GM/T 0004-2012），设计目标是抵抗 collision attack 和 preimage attack。然而，SM3 存在以下限制：

特性	SM3	SipHash
输出长度	256 位	64 位（固定）
密钥化	否	是
碰撞抗性	强	无（信息论安全）
预图像抗性	强	无
适用场景	数字签名、证书指纹	哈希表、分布式系统
性能	较慢（硬件加速）	快（软件优化）

关键区别：

SM3 是无密钥的通用哈希函数，安全性基于计算复杂度
SipHash 是带密钥的哈希函数，安全性基于密钥隐藏

因此，SM3 不能替代 SipHash 用于哈希表场景，因为攻击者可以构造碰撞输入攻击无密钥哈希函数。

与 HMAC-SM3 的对比

HMAC-SM3 是基于 SM3 的带密钥消息认证码（MAC），可以提供身份验证和完整性保护：

CODE

HMAC-SM3(key, message) = SM3((key ⊕ opad) || SM3((key ⊕ ipad) || message))

区别：

HMAC-SM3 输出长度为 256 位，适合需要强安全性的场景
SipHash 输出长度为 64 位，适合哈希表等高性能场景
HMAC-SM3 计算成本较高（需要两次 SM3 运算）
SipHash 计算成本低（仅需 ChaCha 压缩）

选择建议：

需要身份验证和完整性 → 使用 HMAC-SM3
需要抗碰撞的哈希表 → 使用 SipHash
需要通用密码杂凑 → 使用 SM3

安全建议与最佳实践

1. 选择正确的哈希函数

场景一：哈希表

必须使用带密钥的哈希函数
推荐：SipHash-2-4
避免：MurmurHash、CityHash、xxHash（无密钥，易受碰撞攻击）

场景二：数字签名

必须使用抗碰撞的哈希函数
推荐：SM3（国密）、SHA-256（国际）、SHA-3（抗量子）
避免：MD5、SHA-1（已破译）

场景三：消息认证

必须使用带密钥的消息认证码
推荐：HMAC-SM3（国密）、HMAC-SHA-256（国际）
避免：CMAC-AES（无密钥时不安全）

2. 密钥管理

SipHash 的安全性完全依赖于密钥的保密性：

密钥长度：128 位（2 × 64 位）
密钥生成：使用 CSPRNG（如 /dev/urandom、os.urandom()）
密钥存储：加密存储，避免明文写入配置文件
密钥轮换：定期更换密钥，建议每小时或每会话更换

PYTHON

# Python 示例：使用 hashlib 计算 SipHash（标准库不含 SipHash，需第三方库）
 import os
 # 注意：Python标准库不直接提供 SipHash，生产环境建议使用 Rust/Go 实现
 # 或通过 ctypes 调用 libsiphash

 # 生成 128 位随机密钥
 key = os.urandom(16)

 # 实际工程中建议直接使用已有实现：
 # pip install pysiphash  （如果可用）
 # 或调用 Rust/Go 库
 message = b"example message"
 hash_value = 0x0  # 占位符，实际应调用库函数

3. 避免的陷阱

陷阱一：使用无密钥哈希函数作为哈希表

PYTHON

# ❌ 错误：MurmurHash 无密钥，易受碰撞攻击
 # 建议使用带密钥的哈希函数，如 SipHash

陷阱二：硬编码密钥

PYTHON

# ❌ 错误：密钥硬编码在源代码中
 key = b"my-secret-key!!"
 # 应使用os.urandom()生成随机密钥

陷阱三：密钥复用

PYTHON

# ❌ 错误：所有请求使用相同密钥
 # 应该每个请求或会话使用独立密钥
 key = b"shared-key"  # 不应硬编码

总结

SipHash 是密码学哈希函数发展史上的一个重要里程碑，它将对抗安全引入哈希表实现，解决了长期存在的哈希洪水攻击问题。其基于 ChaCha 的设计保证了安全性和性能的良好平衡，已被 Rust、Go、Python 等主流语言采纳为标准库默认哈希函数。

对于国密领域的开发者，需要明确：

SM3 不能替代 SipHash：两者设计目标不同，不能混用
哈希表场景必须使用带密钥哈希：SipHash 是首选方案
数字签名场景必须使用抗碰撞哈希：SM3、SHA-256 等是正确选择

未来，随着量子计算的发展，SipHash 的 64 位输出可能成为瓶颈。届时可能需要迁移到更长输出的带密钥哈希函数（如 keyed SHA-3），但在当前计算能力下，SipHash-2-4 仍是最佳选择。

参考文献

Bernstein, D.J., Duif, N. (2014). "High-speed high-security signatures." Journal of Cryptographic Engineering, 2(2), 77-89. ePrint 2014/266
IETF. "SipHash: a fast pseudorandom function." draft-irtf-cfrg-siphash-13
Rust Standard Library. "std::collections::HashMap." https://doc.rust-lang.org/std/collections/struct.HashMap.html
Python Documentation. "hash() function." https://docs.python.org/3/library/functions.html#hash

← 返回知识库