一、加密基础：对称加密与非对称加密，到底有什么区别？
说到加密，你可能会觉得这是大厂才需要关心的事。
其实不然。我在做接口测试的头两年，也以为加密是开发的事。
直到有一次，我负责一个金融项目的接口校验，发现传输的密码字段居然是明文，吓得我后背一凉——
嗯，从那时起，我就把加密知识补了个扎实。
1.1 对称加密：一把钥匙开一把锁
对称加密，说白了就是——加密和解密用同一把密钥。
就像你家里的门锁，用这把钥匙锁上，也只能用这把钥匙打开。
我在项目中遇到过最经典的对称加密算法，就是 AES。公司内部消息队列的加密传输，用的就是 AES-256-GCM 模式。当时我写测试脚本时，只需要把密钥配好，调用标准库就能完成加解密，确实简单直接。
常见对称加密算法：
| 算法 | 密钥长度 | 特点 |
|---|---|---|
| AES | 128/192/256 bit | 速度快，安全性高，是当前最主流的对称加密 |
| DES | 56 bit | 已过时，容易被暴力破解，不推荐使用 |
| 3DES | 112/168 bit | DES 的增强版，性能较差，逐渐被替代 |
| SM4 | 128 bit | 中国国家密码标准，国内政企项目常用 |
1.2 非对称加密：两把钥匙，分工明确
非对称加密就不一样了。
它有一对密钥：公钥 和 私钥。
公钥可以公开，谁都看得到；私钥只有自己知道。
你想想看，公钥加密的数据，只有对应的私钥才能解开。
这就解决了密钥分发的问题。
常见非对称加密算法：
| 算法 | 密钥长度 | 特点 |
|---|---|---|
| RSA | 1024/2048/4096 bit | 最经典的非对称加密，2048 bit 以下已不安全 |
| ECC | 256 bit | 比 RSA 更安全，密钥更短，性能更好 |
| SM2 | 256 bit | 中国国密标准，基于椭圆曲线，推荐使用 |
非对称加密的典型应用场景：
- 数字签名： 私钥签名，公钥验签，保证身份真实性。
- 密钥交换： 比如 HTTPS 握手时，用非对称加密传递对称密钥。
- 加密传输： 如果只需要单向加密，比如客户端发数据给服务器，客户端用服务器公钥加密即可。
1.3 两者对比：各自的优缺点
| 对比维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 一个密钥 | 一对密钥（公钥+私钥） |
| 加密速度 | 快（快上百倍甚至上千倍） | 慢 |
| 密钥分发 | 困难，需要安全通道传递密钥 | 简单，公钥可直接公开 |
| 安全性 | 依赖密钥保密性 | 基于数学难题，安全性更高 |
| 典型长度 | 128-256 bit | 1024-4096 bit |
| 适用场景 | 大量数据加密 | 密钥交换、数字签名、小数据量加密 |
为什么不全部用非对称加密？
原因很简单——慢。拿 RSA 来说，加密 1KB 的数据可能耗时几毫秒，同样的数据用 AES 加密只需要微秒级。你想想看，一个大型接口每秒要处理成千上万次请求，如果用非对称加密全部数据，服务器早扛不住了。
1.4 混合加密：取长补短的王者
实际项目中，没人会只用一种加密方式。
混合加密才是主流。
具体怎么做？看下面的流程：
这个流程其实就是 HTTPS 的简化版。
我个人习惯把这种模式叫做 “非对称加密铺路，对称加密跑车”。
先用非对称加密安全地传递对称密钥，后续大量的数据就交给 AES 这种高速对称加密来处理。
这样既解决了密钥分发的问题，又保证了性能，一举两得。
1.5 作为测试，你需要重点关注什么？
讲完理论，咱们落地到实际工作。
你作为一个接口测试工程师，在测试加密接口时，核心关注点就这么几条：
- 密钥管理： 密钥是写死在代码里，还是从配置中心动态获取？密钥轮换周期是多少？测试环境、预发布环境、生产环境的密钥是否隔离？
- 加密算法版本： 是否存在已过时的算法（如 DES、RSA-1024）？算法的参数配置是否正确（如 AES 的模式、IV 向量）？
- 加解密边界： 如果加密数据长度超过限制会怎样？解密失败时接口如何返回错误？
- 流程完整性： 证书是否过期？签名是否验证？时间戳防重放是否生效？
一句话总结：
对称加密快但密钥分发难，非对称加密安全但慢，
两者结合才是工业级加密的正确姿势。