你可能会想：加密算法嘛，选一个用不就完了？
我曾经也这么以为。直到有一次帮客户做数据迁移，明明用的是 AES-256，结果对方说拿不到原始数据……折腾了两天才发现——初始化向量 (IV) 写死了，而且密钥长度后台配置成了 128 位。嗯，你想想看，参数差一个比特，安全等级就差了一个数量级。
加密算法参数调试：从入门到实战 - 第1节
1. 加密算法参数调试：为什么参数这么重要
加密算法的核心，说白了就是一套变换规则。而参数，就是这套规则的「旋钮」。拧得对不对，直接决定你能不能打开锁，或者说这把锁到底有多牢靠。
我个人的习惯是，在接触任何加密库之前，先把它的参数清单列出来：哪些是必填的、哪些有默认值、哪些改了之后会影响兼容性。不然等到生产环境出了故障再去查，成本就高了。
1.1 参数决定安全性
最典型的例子是密钥长度。
我记得十多年前，RC4 还算是默认选择。后来因为密钥流预测攻击，慢慢被淘汰。再到现代，AES-128 是保底，AES-256 才敢用于金融级别。参数短一截，攻击者的暴力破解时间就缩短几个数量级。
除了密钥长度，还有初始化向量 (IV) / nonce。
- IV 重复：CTR / GCM 模式下，同样的 IV+密钥 会产生相同密钥流——相当于明文被加密成了同一串密文，直接暴露相关性。
- IV 长度不足：个别库默认 IV 为 0×00 填充，这种配置我在项目里见过好几次，签名验证就是不通过。
避坑指南：我曾经接手过一个遗留系统，它用 AES-CBC 加密用户身份证号，但是 IV 用的是固定 0×00……这就等于没有 CBC 模式的安全性。后来花了很大力气补齐了随机 IV 的逻辑。
1.2 参数影响性能
安全不是唯一目标。你想想看，如果每次加密都跑一万轮迭代，用户的登录就得等两秒，产品经理第一个来找你。
| 参数类型 | 典型值 | 性能影响 |
|---|---|---|
| 密钥派生迭代次数 | PBKDF2: 10 000 - 600 000 | 线性增加每笔加密/解密时间 |
| 哈希函数输出长度 | SHA-256 / SHA-512 | 长输出增加存储与计算开销 |
| 加密模式（GCM vs CTR） | GCM 带认证，CTR 无 | GCM 略慢但更安全 |
这里有个常识：高性能场景推荐用 GCM 的硬件加速版（比如 AES-NI），而资源受限设备（IoT）可以适当降低迭代次数，同时搭配慢哈希函数如 bcrypt 做权衡。
1.3 参数影响互操作性
不同编程语言的加密库，默认参数经常不一致。比如 Java 的 Cipher.getInstance("AES/CBC/PKCS5Padding") 和 Python 的 pycryptodome 默认就差一个填充细节。我当年做跨平台支付接口，就因为填充方式选了 PKCS7 一个字母的差距，调了整整一下午。
常见的互操作性参数包括：
- 填充模式：PKCS7 vs NoPadding vs 01-00 填充
- 加密模式：ECB（不推荐）、CBC、CTR、GCM（推荐）
- 密钥编码：Base64 / Hex / 原始字节
- 数据顺序：大端 / 小端（流密码常见）
我的习惯是：在项目文档里明确写清楚「参数契约」，包括密钥长度、模式、IV 处理方式、填充算法——按这个清单对一遍，跨语言对接一般不会出幺蛾子。
2. 常见参数类型归纳总结
下面这张图帮助你把加密参数体系结构化。你一看就知道哪些参数归安全组，哪些归性能组，哪些是易错点。
3. 参数调试的常见误区
最后聊几个我踩过的坑，你可以当个 checklist 来用。
3.1 把 Demo 参数直接上生产
很多教程里为了演示，会用 "AES/CBC/PKCS5Padding" 的写法，结果不少同学拿到生产里也用这个。但是 Java 的 PKCS5Padding 其实和 PKCS7Padding 在 AES 下效果一样，但不同库的默认填充方式可能不同——我见过因为这个问题跨平台解密失败的案例。
3.2 忽略密钥派生函数参数
你以为用个 hashlib.sha256 就把密码转成密钥了？错。现代加密标准要求用 PBKDF2、bcrypt、scrypt 或 Argon2。直接哈希会引入彩虹表攻击。我建议把迭代次数设成不低于 100 000，服务器性能允许的话可以更高。
3.3 混淆对称与非对称参数
RSA 的密钥长度是 2048 或 4096 位，而 AES 是 128/192/256 位。有人会把 RSA 的 2048 当作 AES 的密钥长度用——结果算法直接报错。别笑，我在代码 review 里见过两次。
个人经验：每次新建加密模块，先写一个参数表，明确每种参数的类型、有效范围、默认值，然后让另一位同事 review 一遍。这样能过滤掉 80% 的低级错误。
曾经有一个项目，加密后的密文用 base64 输出，但没指定行宽，导致某客户端解析时出错。嗯，编码参数的小问题有时候很难定位，但一旦出问题就是大返工。
4. 小结
参数调试不是写代码时才想的，而是从设计阶段就要考虑的。我把这一章的内容浓缩成三个问题，你每次遇到加密场景都问一遍自己：
- 这个参数如果错了，安全会被攻破吗？
- 这个参数如果选了最安全的，性能扛得住吗？
- 这个参数和其他系统对接时，两边默认一致吗？
记住这三个问题，后面的章节我们再深入到具体算法里一点点调参数。