📚 课程目录第4章 FPE标准概览

第四章：FPE标准概览——NIST SP 800-38G，FF1、FF3、FFX

前面我们聊了格式保持加密的基本概念和为什么你需要它。现在，得把标准请上台了。

你想想看，没有标准会怎样？各家用各的算法，接口乱七八糟，互操作性基本为零。2016年NIST发布了SP 800-38G，这事才算有了规矩。今天我们就来拆解这个标准，以及里面定义的FF1、FF3，还有没进标准但实际很火的FFX。

个人习惯：每次接触新的密码标准，我第一件事就是去看它的适用范围和安全性声明，而不是先看算法细节。这能帮你节省大量时间，避免选了不该选的方案。

4.1 NIST SP 800-38G 说了什么？

NIST SP 800-38G 的正式名称是《Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption》。说白了就是告诉你：在分组密码（比如AES）上面，怎么包装出两个具体的FPE算法——FF1和FF3。

为什么只有两个？我当年看第一版的时候也挺纳闷。后来研究历史才明白，FF1是从FFX方案里提纯出来的，FF3则是针对更小域（比如6位数字的信用卡CVV）优化的版本。标准里专门写了安全性声明和测试向量，方便你验证实现是否正确。

标准/方案	发布年份	状态	核心特点
NIST SP 800-38G	2016	当前标准	定义FF1和FF3
FF1	2002 (原始Feistel)	推荐使用	域大时安全，支持任意长度
FF3	2014(提出)	谨慎使用	域小(≥2)，但2017年发现漏洞
FFX	2002-2010	未进标准	灵活但不标准，工业界广泛

我曾经踩过的坑：2018年有个项目要用FPE加密6位数字的PIN码。我直接用了FF3，结果后来读发现FF3在域大小等于2的倍数且轮数不够时有倾斜攻击。幸好项目还在测试阶段，赶紧换成了FF1并增加轮数。这段经历让我养成了每次都要查最新安全性分析的习惯。

4.2 FF1——最稳的FPE算法

FF1本质是一个7轮Feistel网络。它把输入字符串分成左右两半（如果长度是奇数，右半会比左半多一位）。每轮用AES+密钥生成伪随机数，和右半异或再替换左半。

为什么是7轮？我翻过一些安全证明，6轮在某些信息泄露下不完美，7轮达到了超伪随机置换的级别。嗯，你不需要背证明，但要知道：少一轮都不安全。

支持任意长度，最小2个字符
域可以是字母、数字、自定义字符集
内部使用CMAC/AES-CBC-MAC计算PRF
安全性经过多年数理验证

现实项目中，90%以上的FPE需求都可以用FF1解决。我在金融系统里处理信用卡卡号、身份证号、车牌号，清一色用FF1。唯一要注意的是性能——因为每轮都调用AES加密，加密大量短字符串时可能成为瓶颈。

# FF1算法的典型参数结构（Python伪代码）
# 实际实现建议使用成熟的库，比如pyffx或cryptography
class FF1:
    def __init__(self, key, radix=10, max_len=20):
        self.key = key
        self.radix = radix    # 字符集基数，数字是10
        self.max_len = max_len
        self.rounds = 7       # 固定7轮
        
    def encrypt(self, x, tweak=b''):
        # 将字符串x转换为数字数组
        # 运行7轮Feistel
        # 返回密文字符串
        pass

实战要点：FF1的tweak（调整值）不是可选的！官方标准里说tweak可以是空字节串，但安全性证明假设tweak是公开随机的。实际部署时，应该为每个上下文使用唯一的tweak（比如用户ID+时间戳）。这是很多人容易忽视的细节。

4.3 FF3——小而美的困境

FF3是为处理极短字符串设计的。当你要加密“卡有效期（MMYY）”这种4位数字，或者“账户最后4位”，FF3能处理的最小域长度是2个字符。它只有8轮，比FF1少，所以性能更好。

但2017年，Dworkin（就是NIST标准的主要作者）自己发现了FF3的弱点。当域大小是偶数且轮数恰好为8时，存在一种区分攻击。后来更新的NIST SP 800-38G Rev.1把FF3改成了FF3-1，引入了额外的密钥派生步骤以修复漏洞。

我的建议很直接：除非你明确知道自己在做什么，并且分析了威胁模型，否则不要用FF3-1。能用FF1就用FF1。

避坑指南：我曾经接手过一个遗留系统，里面用的是旧版FF3（8轮，无密钥派生）。迁移时发现所有加密数据都要解密重加密。因为旧标准没有正式的测试向量，我只能对着原始逐个验证。所以千万别在生产环境里用没进标准的“民间版本”FPE。

4.4 FFX——标准的候补选手

FFX（Format-Preserving Feistel-based Encryption）其实是一个框架，不是单一算法。它由Rogaway等人提出，定义了Feistel网络用于FPE的通用结构。FF1和FF3都是FFX的特例。

为什么没进NIST标准？嗯，标准委员会最终选择了两个具体实例，而不是一个宽泛的框架。框架意味着太多实现自由度，容易导致不一致。

但工业界一直用FFX。比如在以太坊的区块链数据脱敏、某些数据库加密中间件里，你都能看到FFX的实现。它支持自定义轮数（通常6-10轮），还可以调整Feistel结构。

# FFX框架的通用伪代码（不是标准实现，仅用于理解）
def ffx_encrypt(key, message, tweak):
    # 预处理：计算a,b,c,d等参数
    # 将消息转为数字表示
    # 运行指定轮数Feistel
    # 输出加密后的数字表示的字符串

我个人对FFX的态度：如果你在造轮子——比如写一个内部工具，且保证只有你自己用，FFX的灵活性很诱人。但如果是商业项目或合规场景，老老实实用NIST标准里的FF1。

4.5 各标准的对比与选型

特性	FF1	FF3/FF3-1	FFX（非标准）
最小域长度	2	2（FF3-1要求≥2）	通常≥2
轮数	7（固定）	8（FF3-1固定）	可配置（典型8-10）
安全性	高（经多年分析）	中等（修复后稍好）	依赖配置
标准状态	NIST推荐	NIST可选	无官方背书
性能（短字符串）	中等	快	可调
实现复杂度	中等	中等	低（框架简单）

选型其实不复杂。如果你要合规（比如金融监管要求），必须用FF1。如果性能敏感且可接受风险，FF3-1可以。FFX只适合实验或封闭环境。

这张图清晰展示了标准体系的脉络。你可以看到FF1在左，FF3在右，FFX在更右侧。底部用了一个红色圆角框强调我的建议——其实也是业界共识。

小技巧：如果你用Python，推荐cryptography库的FormatPreservingEncryption模块。它实现了FF1且经过了OpenSSL审核。自己撸一个FF1在周会上可能很酷，但出bug了谁负责？

4.6 实现时的几个关键点

最后分享几个我在实现和集成FPE标准时积累的经验。

字符集映射：标准要求把字符映射到0..(radix-1)的数字空间。如果字符集包含中文字符，radix会很大，性能会受影响。我一般先用base编码压缩字符集。
tweak使用：很多人以为tweak是密文的一部分，但它更像是“上下文标识”。同一个明文在不同tweak下会变不同密文。你想想看，如果两张卡号的tweak一样，攻击者就可能根据长度推断关系。
轮数不要乱改：尤其是FF1，官方论证过7轮。少一轮可能被差分攻击检测到。我见过有人想节省性能改成5轮……后果可想而知。
测试向量验证：NIST SP 800-38G的附录C里有FF1和FF3的测试向量。实现完后必须跑一遍，确保和官方输出一致。

# 使用cryptography库实现FF1的示例（简化版）
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import padding

# 实际使用请参阅官方文档，这里仅展示概念
# ff1 = FormatPreservingEncryption()  # 伪代码
# encrypted = ff1.encrypt("1234", tweak=b"user_id_42")
# print(encrypted)  # 输出格式保持的密文

好了，关于FF1、FF3和FFX，以及它们背后的NIST SP 800-38G标准，我们算过了一遍。记住，标准不是用来背的，是用来查的。下次你需要在项目里集成FPE，直接翻回这一章，就能快速找到该用哪个、要注意什么。