📚 课程目录第3章 FPE核心概念

FPE 核心概念：明文格式、密文格式、保持长度、保持字符集

大家好，我是你们的老朋友。今天咱们来聊聊 FPE 的几个核心概念。

说实话，很多刚接触 FPE 的同学，一开始都会被这些术语搞得有点晕。什么格式不格式的，加密就加密呗，干嘛这么麻烦？

嗯，当年我刚开始做金融数据处理时也是这么想的。直到被业务方怼回来：“你这个密文长度变了，我们数据库字段装不下！”——从那以后，我就再也不敢小看这几个概念了。

说白了，明文格式就是你的原始数据长什么样。

比如一个身份证号：

110101199001011234

它有什么特点？

我在项目中遇到过一种情况：有人想把身份证号整个当字符串加密，结果密文里冒出了字母“X”。业务系统一校验，诶？格式不对，直接报错。所以，明文格式是 FPE 的前提，你必须先搞清楚它。

    核心要点：FPE 的“格式”指的不是文件格式，而是数据的语法约束——长度、字符集、结构。

密文格式就更好理解了。就是加密之后，数据变成什么样。

对于传统加密来说，密文格式不是重点。AES 加密出来的就是一堆二进制，管你原来的数据是啥。

但 FPE 不一样。FPE 要求密文格式和明文格式完全一致。还是刚才那个身份证号：

看到没？密文依然是 18 位纯数字。业务系统拿过来就能用，完全不需要改字段类型。

一点小经验：我在做社保号加密时，发现有些字段虽然表面是数字，但其实包含隐藏的校验位。加密后校验位失效了，业务系统就报“号码不合法”。所以，你不仅要保持字符集，还得考虑业务规则。

这个最好理解。保持长度就是：明文多长，密文就多长。

为什么这是个硬性要求？

我曾经踩过一个坑：一个信用卡 CVV 项目，明文是 3 位数字。我用 FF1 算法加密，输出也是 3 位数字。看起来没问题对吧？但我忘了 CVV 有一个校验规则：首位不能是 0。结果生成了一批首位是 0 的密文，业务系统直接乱套了。

避坑指南：保持长度不仅仅是位数相同，还要保持语义上的合法性。比如月份不能超过 12，日期不能超过 31。这些约束 FPE 算法本身不会帮你处理，你得自己想办法映射。

字符集指的是明文所使用的所有合法字符的集合。

最常见的字符集：

FPE 加密的密文，里面的每个字符都必须在原始字符集里。不能突然冒出个英文标点或者汉字。

    举个栗子：假设明文是一个车牌号“京A12345”，字符集包含：汉字（京、沪、粤...）、大写字母（A-Z）、数字（0-9）。FPE 加密后的密文，比如“沪B67890”，虽然内容变了，但依然由汉字、字母、数字构成，且长度不变。

说了这么多，咱们画张图总结一下。这张图展示了 FPE 的核心逻辑，也是我这十年来做加密项目最常用的思维框架：

其实说到底，FPE 的存在就是为了解决一个现实问题：如何在加密的同时，不改变系统现有架构。

想想看，如果只是长度和字符集变了，但业务逻辑里有个字段叫“证件号码”，长度18，你改成32了——好，前端要改校验，数据库要改表，接口要改文档，存储过程要改，备份脚本要改......成本飙升。

FPE 通过严格保持格式，让你做到：

我个人的习惯：在开始任何 FPE 项目前，我都会先拉一个清单，把每个字段的“格式定义”写得清清楚楚。包括字符集、长度、校验规则、特殊约束。这个清单越细，后面踩的坑越少。

好了，今天的核心概念就聊到这儿。记住这四个字就行：格式即约束，约束即规则。搞清楚了这些，后面学 FPE 的各种算法就会轻松很多。