FF1 算法详解：参数、步骤与安全约束归纳总结

FF1 是目前应用最广泛的格式保持加密算法，没有之一。我最早接触它是在一个信用卡号脱敏项目里，需求是「加密后长度不变、字符集不变，还要能反向解密」。当时调研了一圈，最后选了 NIST SP 800-38G 里定义的 FF1。今天咱们就把它拆开揉碎了讲——参数、加密步骤、还有那些容易踩坑的安全约束。

1. 核心参数：你得先认清这五个

FF1 的参数长得有点啰嗦，但每个都不能少。我在一次方案评审里见过有人把 tweak 长度设成 0，结果合规检查直接不通过。下面这张表帮你理清脉络：

2. 加密步骤：一个迭代的 Feistel 结构

FF1 本质上是一个经过调整的 Feistel 网络。你想想看，一个 Feistel 结构把明文分成左右两半，一轮一轮地做非线性变换——FF1 在此基础上加了 tweak 和 radix 的适配。步骤拆解如下：

1. 分拆明文：将长度为 n 的明文（数字串或字符串）拆成左半 A（长度 u = floor(n/2)）和右半 B（长度 v = n - u）。
2. 计算中间值：用 PRF(key, tweak + A_integer) 生成一个伪随机数流，转成 radix 进制表示，长度等于 v。
3. 更新右半：将上一步的伪随机数串与 B 按位模加（radix 下的加法），得到新的 B'。
4. 交换左右：将 A 和 B' 交换，作为下一轮的输入。
5. 重复 10 轮：FF1 固定迭代 10 轮。每轮使用不同的 round counter 参与 PRF 计算。
6. 最终输出：将最后一轮的 A 和 B 拼接成加密后的字符串。

解密步骤刚好反过来——轮函数用同样的 PRF，但加减法互换。说白了就是把加密流程倒着跑一遍。我曾在一个安全 SDK 里实现过两端自动切换，核心逻辑不超过 30 行。

3. 安全约束：这些红线不能碰

FF1 虽然经过了标准化，但使用不当照样会翻车。我记得有一篇专门指出了 FF1 在特定 radix 和 tweak 组合下的攻击面。下面是几条必须遵守的约束：

• 最小明文长度 ≥ 2：算法内部依赖左右拆分，如果 n=1 则无法执行 Feistel 结构。NIST 标准直接规定 minlen 至少为 2。
• tweak 应具备唯一性：在同一个密钥下，尽量保证每个密文使用不同的 tweak。例如可以用记录 ID + 时间戳拼接。我曾经遇到过线上一个缓存键冲突，就是因为多个加密记录用了同一个静默 tweak（全是空字节），蜜文全部重复，排查了很久才发现。
• 禁止直接使用明文作为 tweak：这样做会破坏 FPE 的安全性基础，攻击者很容易构造选择明文攻击。
• Radix 上限 2^16：官方建议 radix ≤ 65536，否则内部算术运算可能溢出或性能骤降。一般场景下我们只用 10/16/36/62 这几个常用值。
• 密钥周期管理：FF1 的加密速度较慢（比 AES-GCM 慢一个数量级），所以密钥复用次数需要控制。我建议单个密钥加密的记录数不超过 10^8 条，并定期轮换。

// FF1 加密的伪代码（简化）
function FF1_Encrypt(key, tweak, radix, plaintext):
    n = len(plaintext)
    u = floor(n/2)
    v = n - u
    A = plaintext[0:u]
    B = plaintext[u:n]
    
    for i in range(10):
        // 生成伪随机数流（转为 radix 进制，长度 v）
        prf_output = AES_CMAC(key, tweak + int_to_bytes(A) + i)
        prf_radix = bytes_to_radix(prf_output, radix, v)
        // 模加法
        B_new = (B + prf_radix) mod radix
        // 交换
        A, B = B_new, A
    
    return A + B