📚 本文属于专题：数据安全与国密加密
什么是格式保留加密
普通加密（如 SM4、AES）的输出是一串二进制密文，长度和字符集都变了。一个 11 位手机号加密后可能变成一长串 Base64，原本 varchar(11) 的字段存不下，所有读写这个字段的代码都要改。
FPE 的特点是：密文和明文在长度、字符集、格式上保持一致。手机号加密后仍是 11 位数字，邮箱加密后仍是合法邮箱格式。这样数据库表结构不用动，前端展示不用改，存量系统改造量大幅降低。
FPE 解决什么问题
典型场景是老系统的敏感字段加密改造：数据库里早就堆满了手机号、身份证号、银行卡号，现在要做数据安全合规（数安法、个保法、密评），必须加密存储，但又不能把跑了多年的业务代码全部重写。
- 字段长度/类型不变：免去改库表、改 ORM、改接口的连锁成本。
- 保留部分可用性：可以只加密身份证号的中间几位，保留前 6 位地区码用于统计。
- 兼容校验规则：银行卡号加密后仍能过 Luhn 校验位的格式，不会被前端拦截。
FPE 的标准与算法
国际上 FPE 的权威标准是 NIST SP 800-38G，定义了两种模式：FF1 和 FF3-1（FF3 因安全问题已被修订为 FF3-1）。它们底层都基于分组密码（如 AES），通过 Feistel 结构在指定基数（radix）和长度上做加密。
| 模式 | 底层 | 特点 | 说明 |
|---|---|---|---|
| FF1 | 分组密码 | 支持更长输入、更灵活 | NIST 推荐 |
| FF3-1 | 分组密码 | 实现更简单、更快 | FF3 修订版，修复了已知弱点 |
在国密合规场景下，可以将 FPE 的底层分组密码替换为 SM4，从而在保留格式的同时满足国密算法要求。这也是 FPE 与密评结合时的关键点。
为什么 FPE 需要硬件密码机
FPE 的安全性几乎完全压在密钥保护和算法实现正确性上。这正是硬件密码机（HSM/密码卡）的价值所在：
FPE 和脱敏、Tokenization 的区别
| 技术 | 可逆 | 格式保留 | 典型用途 |
|---|---|---|---|
| FPE | 可逆（有密钥可解密） | 是 | 生产数据加密存储 |
| 静态脱敏 | 不可逆 | 通常是 | 测试/分析环境造数 |
| Tokenization | 可逆（查映射表） | 是 | 支付卡号替换 |
简单说：要能解密还原且不改格式，选 FPE；只是给测试环境造假数据，用脱敏；不想自己保管密钥、愿意维护映射表，可考虑 Tokenization。
落地建议与结论
FPE 是存量系统做敏感字段加密、又要控制改造成本的"最小侵入"方案。但它的安全性高度依赖密钥管理和算法实现，不要用软件库裸跑在业务服务器上。推荐路径：FPE 运算下沉到硬件密码机或密码服务平台，业务系统只调加解密 API，根密钥进 KMS 统一管理，这样既保留格式、又满足密评对合规密码产品的要求。
如果你正在评估老系统的字段加密改造，可以联系我们，结合你的数据库结构给出 FPE 与硬件密码机的接入方案。