Safaricom 200万号码变哈希

肯尼亚移动支付巨头 Safaricom 去年干了件让开发者集体骂街的事：M-Pesa 的回调接口里，手机号字段突然从「2547*****126」变成了 64 位十六进制字符串。没有公告，没有迁移文档，你的支付系统直接宕机。

这就是 SHA256 哈希。数学上不可逆，理论上无解。但一位开发者用 73 秒和 7.2GB 存储空间，把整个国家的手机号空间做成了「彩虹表」——查询速度压到亚毫秒级，成本降到一次 S3 请求。

200 million：一个封闭空间的暴力美学

肯尼亚 Safaricom 的号码规则很干净：2547XXXXXXXX 和 2541XXXXXXXX，恰好 2 亿个组合。不是「上亿」，是精确到个位的 200,000,000。

哈希计算是 CPU 密集型，但 2 亿次 SHA256 在现代笔记本上只是分钟级任务。作者把任务拆到 12 个 CPU 核心，每个 worker 独立哈希、排序，最后流式归并。73 秒后，一个 7.2GB 的二进制文件落地。

每条记录 36 字节：32 字节哈希 + 4 字节索引。按哈希值排序，这是后续二分查找的前提。

文件结构决定了查询效率。内存映射（mmap）让这个 7.2GB 的「庞然大物」无需全量加载，操作系统页缓存会把热点数据留在内存里。 warmed-up 后的查询，本质上是在内存里做 28 次比较。

从 2 分钟到 0.3 毫秒：二分查找的降维打击

最原始的方案是实时暴力枚举：收到回调时，现场哈希 2 亿个候选号码比对。耗时约 2 分钟——API 早超时了，支付流程直接卡死。

预计算 + 排序 + 二分查找，把时间复杂度从 O(n) 打到 O(log n)。28 次比较，每次从磁盘拉 36 字节，实际运行稳定在 0.3 毫秒以内。

代码很直白：mmap 映射文件，lo/hi 双指针，mid 取中，哈希值比较，缩半区间。这是算法导论第 2 章的内容，但放在生产环境里，它解决了一个「理论上无解」的问题。

关键洞察：手机号空间是封闭且可枚举的。这个前提让「不可能」变成「工程问题」。

7.2GB 怎么塞进 Lambda？S3 的 206 分片请求

云原生场景下，下载 7.2GB 到 Lambda 容器不现实。作者的做法是把文件切片存 S3，查询时用 HTTP Range 请求只拉取需要的分片。

二分查找的 28 步里，每一步的位置可预测。预先把文件按 1MB 或更大块切片，查询时通过计算直接定位到目标切片，单次请求几百 KB。28 次请求串行太慢，但二分查找的访问模式有局部性——上层节点的频繁命中会被缓存，实际请求数远小于理论值。

更激进的优化：把文件顶层节点常驻内存，或者干脆用 CloudFront 边缘缓存。作者没展开，但架构方向很明确：把存储成本压到接近零，查询延迟压到个位数毫秒。

整个方案的运行成本：一次 S3 GET 请求，约 0.0004 美元。对比实时哈希的 2 分钟 CPU 燃烧，这是四个数量级的差距。

哈希「脱敏」的幻觉：当设计假设撞上工程现实

Safaricom 的改动本意是脱敏。把明文手机号换成哈希，表面上去除了敏感信息——前提是攻击者无法建立「哈希→原值」的映射。

但手机号不是密码。密码空间理论上无限，用户可选任意字符组合；手机号是运营商分配的、格式固定的、空间有限的标识符。2 亿个候选，在离线计算面前毫无秘密可言。

这不是 Safaricom 独有的问题。任何用哈希「保护」低熵标识符的方案，都面临同样的攻击面：身份证号、信用卡号、甚至某些短域名系统。只要原始空间可枚举，预计算攻击就是悬在头顶的剑。

作者没提防御方案，但隐含答案很明显：加盐。每个用户独立的随机盐值，把 2 亿×1 的查询空间膨胀到 2 亿×N，N 是盐值空间大小。代价是存储和查询复杂度，但安全模型从「防不住」变成「算不起」。

一个细节：作者的代码里，盐值字段是空的。这不是 oversight，是对原始问题的忠实还原——Safaricom 没加盐，所以攻击可行。

这个方案在 GitHub 上的讨论区，有人问了作者一个尖锐问题：如果 Safaricom 明天把哈希换成 HMAC-SHA256 带密钥，你的 7.2GB 文件是不是瞬间变废铁？作者回复：「是的。但那是另一个故事了。」