第1章 FF1算法概述：从何而来，用在何处
大家好，我是你们这门课的主讲人。
在正式开始之前，我先说个题外话。大概十年前，我接手过一个金融项目——要对数据库里的信用卡号做脱敏。业务方丢过来一句话：“字段长度、格式都不能变，正则校验还得过。” 当时我翻遍了加密算法库，AES、DES、国密SM4全都试了个遍，输出要么是二进制乱码，要么长度翻了倍。那会儿我才真正意识到：世界上确实有一种加密，叫“格式保持加密”，而这玩意儿在标准库里的实现，少得可怜。
今天我们就来讲讲这个领域的明星算法——FF1。
1.1 什么是格式保持加密
先别急着看FF1。我们得先搞清楚一个更基础的概念：格式保持加密（Format-Preserving Encryption，简称FPE）。
说白了，FPE就是一种“输出格式和输入格式一模一样”的加密。你送进去一个16位的信用卡号，出来还是16位数字；你送进去一个符合正则的身份证号，出来还是那个格式的身份证号。但是，内容已经完全变了，只有持有密钥的人才能还原。
你想想看，这在现实中有多实用？
- 数据库不需要改字段类型、长度
- 旧系统不需要改正则校验逻辑
- 前端界面不需要改输入框限制
这正是FPE的核心魅力——零入侵。
1.2 FF1算法的诞生背景
FPE的理念虽然好，但在FF1出现之前，实现它却并不容易。早期有一些基于Feistel网络手工搓出来的方案，但缺乏安全证明，也不敢用在严肃的生产环境里。
转机出现在2016年。美国国家标准与技术研究院（NIST）发布了SP 800-38G标准，正式收录了两种FPE模式：FF1和FF3。其中FF1就是我们这门课的主角。
我记得很清楚，当时标准一出来，安全圈里立刻炸了锅。为什么？因为它终于提供了一个经过严格安全论证、可公开实现、可自由使用的FPE方案。
| 项目 | 说明 |
|---|---|
| 标准化组织 | 美国NIST |
| 标准编号 | SP 800-38G（2016年发布） |
| 核心设计 | 基于平衡Feistel网络 + AES/CMAC |
| 支持字符集 | 数字、字母、自定义字符集 |
| 安全强度 | 可证明安全（达到PRP安全级别） |
FF1的设计思想其实很聪明——它没有推翻现有密码学基础，而是把AES这类成熟的“块加密算法”套进一个特殊构造的Feistel网络里，再配合合理的“整数映射”技术，最终实现了格式保持。
1.3 FF1算法的典型应用场景
聊完背景，咱们看看FF1到底能用在什么地方。说实话，它的应用场景比大部分人想象的更广。
1.3.1 金融数据脱敏
这是最常见的场景。信用卡卡号、银行账号、手机号，这些字段在数据库中通常都有固定长度和格式约束。用FF1加密后，你拿到的密文依然是合法的卡号格式——能通过Luhn校验，能存进原来的字段，能正常展示。
我遇到过最极端的一个需求：某个支付系统的数据库字段被硬编码为CHAR(16)，而且不允许改表结构。用FF1一天就搞定了，如果换别的方案，估计得折腾一个月。
1.3.2 个人身份信息保护
身份证号、护照号、社保号这类敏感信息，在测试环境、开发环境里经常需要脱敏。使用FF1，你可以做到：
- 保持“18位数字”格式不变
- 保持“前6位地区码”的映射关系（可选）
- 保持对现有代码的完全透明
1.3.3 数据库字段加密
很多数据库提供了透明数据加密（TDE），但TDE是“全页”加密。如果你只想加密某个字段，又不想改应用程序，FF1几乎是唯一的选择。
1.3.4 通信协议中的短数据加密
有些老旧协议里，字段长度是固定的，没法扩展。FF1可以在字节数不变的前提下完成加密，这在物联网、支付终端领域非常实用。
1.4 FF1与格式保持加密的整体关系
为了帮你更清楚地理解这门课的知识结构，我画了一张图。
从这张图你可以看到，FPE是一个大类，下面有FF1、FF3等具体实现。而FF1是其中最成熟、应用最广、实践文档最丰富的一个。这门课程的核心，就是让你彻底搞懂FF1的数学原理、工程实现和避坑指南。
1.5 为什么你需要学习FF1
我猜你可能会问：“我直接调库不就行了吗？为什么还要学算法细节？”
嗯，这个问题很实在。我当年也这么想过。
但后来在项目中踩了几个坑之后，我明白了：
- 调库解决不了参数选型——字符集怎么选？Radix怎么配？Tweak长度设多少？这些都要理解原理才能做对。
- 调库解决不了性能瓶颈——FF1的Feistel轮数、中间数据的编码方式，都会影响你的吞吐量。不懂原理，你连优化的方向都找不到。
- 调库解决不了安全审计——很多安全审计官会问你：“你的FF1实现是否符合NIST标准？你的Tweak生成策略是什么？” 答不上来，审计就挂了。
所以，欢迎进入FF1的实践世界。这门课我会带着你，从数学基础走到工程落地，把每一个坑都踩一遍——当然，我会提前告诉你哪里该绕开。