第3章：历史背景与标准化过程 —— FF1 和 FF3 是怎么来的
说实话，我刚接触格式保留加密那会儿，还以为这玩意儿是近几年突然冒出来的。后来翻了翻资料才发现，FF1 和 FF3 背后折腾了快二十年。这一章我就带你捋一捋它们的历史背景和标准化过程，看看 NIST 是怎么把这两套方案推到台前的。
3.1 为什么需要格式保留加密？—— 一个老问题
大家都知道，传统的 AES、DES 加密出来的是一堆乱码。但在很多场景里，你输出乱码就是不行。举个实际例子：信用卡卡号 16 位纯数字，加密后你总不能变成 32 位十六进制吧？银行系统里的数据库字段长度、格式都写死了，改不了。
这就是格式保留加密（FPE）要解决的痛点：密文和明文保持 相同的数据类型和长度。说白了，就是加密前后看着像同一类东西。
最早的需求其实来自美国的社会安全号码（SSN）和信用卡行业。我记得大概 2008 年左右，我参与过一个金融项目，客户要求把数据库里的敏感字段加密，但应用层代码一行都不许改。那会儿还没成熟的 FPE 标准，我们只能在 AES-CTR 外面裹一层循环截断，丑得要命。
3.2 学术界的早期探索
FPE 的理论基础可以追溯到 80 年代，但真正有工程意义的构造法是 21 世纪初才成型的。下面这张表帮你看清楚关键节点：
| 时间 | 事件 | 贡献者 |
|---|---|---|
| 2002 | 提出基于 Feistel 网络的 FPE 构造思路 | Black、Rogaway |
| 2004 | 给出第一个严格证明的 FPE 方案 | Bellare 等 |
| 2009 | 推出 FFX 模式（Format‑Preserving Feistel） | Bellare、Rogaway、Spies |
| 2011 | Volt 公司提交 FF1、FF2、FF3 草案给 NIST | Terence Spies（Volt） |
2009 年的 FFX 模式是里程碑。它把 Feistel 网络和 AES 揉在一起，既能保留格式，又能用现成的加密硬件。我当年第一次读到 FFX 时就一个感觉：这东西靠谱，但实现起来细节特别多。
3.3 NIST 标准化过程 —— 漫长的筛选
NIST 在 2010 年启动了对 FPE 标准的正式征集。我当时正好在关注这个领域，每周刷邮件列表。竞争方案大概有五六种，最后入围的是 Volt 公司提交的三个变体：FF1、FF2、FF3。
为什么最后只选了 FF1 和 FF3？
- FF1：设计最保守，安全边界最清晰。它的圈数多（10 轮），但安全性分析也最充分。
- FF2：被淘汰了。因为它在中间步骤里用了异或而不是加法，导致漏洞。我记得当时邮件组里吵了两个月。
- FF3：圈数少（8 轮），性能好。早期大家以为它足够安全，结果几年后出事了（这个我后面会细讲）。
2016 年，NIST 正式发布 SP 800‑38G，把 FF1 和 FF3 写进推荐标准。2019 年又更新了一次，主要是针对 FF3 的安全漏洞做了补充说明，建议别再继续用 FF3‑1。
关键时间线：2011 年提交草案 → 2013 年公开讨论 → 2016 年正式发布 → 2019 年修订版。
3.4 FF1 和 FF3 的标准化背景对比
下面这张表能帮你快速区分两个标准在诞生背景上的差异：
| 维度 | FF1 | FF3 |
|---|---|---|
| 核心设计者 | Bellare、Rogaway、Spies | 同 FF1（来自同一套 FFX 框架） |
| 设计目标 | 高安全性，保守参数 | 高性能，减少圈数 |
| 标准化时的状态 | 几乎无公开攻击 | 起初认为安全，后被攻破 |
| NIST 最终态度 | 推荐用于所有场景 | 2019 版建议谨慎使用（仅限小域+限制次数） |
我个人经验：2017 年我在做合规审计时，很多厂商都在推 FF3 因为快。我当时的建议是“能上 FF1 就上 FF1，除非压测实在过不了”。结果两年后 NIST 的警告就出来了……嗯，有时候保守真能救命。
3.5 标准化背后的人与故事
你可能好奇，为什么是 Volt 公司提交的方案？Volt 是一家做数据安全的小公司，创始人 Terence Spies 之前专门做数据库加密。他带着 FFX 框架去 NIST，属于典型的“业界反哺学术界”。
标准化过程中还有一个插曲：NIST 原本想只推一个方案，但社区里吵起来了。一派嫌 FF1 太慢，另一派嫌 FF3 不安全。最后 NIST 妥协，把两个都放进去，让用户根据场景自己选。我个人觉得这个决定挺聪明的，既给了选择权，又避免了一刀切。
3.6 一张图看懂发展脉络
下面的 SVG 图把整个标准化流程串了起来。你看了这张图，基本上就能把刚才说的这些节点串在一起：
避坑提醒：我曾经见过项目组在 2018 年直接拿 FF3 做核心模块，根本没关注 NIST 2019 的更新。结果后来被合规团队要求全部换回 FF1，改代码改到崩溃。所以如果你现在还在用 FF3，请一定确认用的是 FF3-1 版本，并且限制消息次数不超过 2^32。
3.7 一点个人总结
FF1 和 FF3 的标准化过程，说白了就是学术界和工业界互相磨合的结果。NIST 没有一口气定死，而是给了大家选择空间。但正因如此，我们作为工程师，必须理解这两个方案各自的“脾气”。
下一部分我们就要进到具体的算法构造了。不过在那之前，你先记住一句话：FF1 是稳重派，FF3 是激进派。选哪个，取决于你的场景有多大的容错空间。