对称加密与非对称加密：算法基础与实战选型
加密算法是整个密钥边界架构的基石。这块内容，我建议你不仅要会配，还要明白背后的权衡。说白了，选错了算法，边界再漂亮也是纸糊的。这一章，我们就把对称加密和非对称加密的核心算法、密钥长度选择以及性能差异讲清楚。
对称加密：AES 是唯一的主流选择
对称加密，加密和解密用的是同一把密钥。速度快，适合加密大量数据。现在的主流，基本就是 AES 的天下了。
AES（Advanced Encryption Standard）
AES 有三种密钥长度：128、192 和 256 位。块大小固定为 128 位。我个人习惯，在边界防护场景中，默认选 AES-256。为什么？
- AES-128：安全强度足够，性能极佳。适合对性能要求极度苛刻的场景，比如硬件加速卡。
- AES-256：安全冗余更高，能抗住未来的量子计算威胁（虽然还很远）。我参与过的金融核心交易系统，数据落盘加密全部强制 AES-256。
- AES-192：中间状态，用得最少。除非合规要求明确指定，否则我一般直接跳过。
还有一个重要的点是 工作模式。AES 本身是块加密，需要配合模式来使用。常见的模式有：
| 模式 | 特点 | 典型场景 |
|---|---|---|
| ECB | 简单，但相同的明文块会生成相同的密文块 | 别用。我见过有人拿 ECB 加密图片，结果轮廓还在，太可怕了。 |
| CBC | 需要 IV，加密串行，解密可并行 | 传统文件加密，但已逐渐被 GCM 取代。 |
| CTR | 将块密码变成流密码，可并行 | 磁盘加密场景。 |
| GCM | 自带认证，能检测篡改 | 我强烈推荐。网络传输、API 加密的首选。 |
避坑指南：我曾经在一个项目中接手别人的代码，发现他用 AES-ECB 加密用户的登录凭据。没有 IV，相同的密码加密后结果完全一样，这跟明文存储没什么区别。我花了一周时间，把所有数据重加密为 AES-256-GCM，顺便加上了轮换逻辑。
选 AES-GCM 模式。它既是加密，又是完整性校验，省掉了你单独算 HMAC 的麻烦。性能上现代 CPU 都有 AES-NI 指令集加速，完全不用担心。
非对称加密：RSA 还是 ECC？
非对称加密，公钥加密，私钥解密。速度慢，但解决了一个核心问题：密钥分发。在边界架构里，它主要用来做密钥协商和数字签名。
RSA
RSA 是老兵，应用极广。它的安全性基于大整数分解的难度。密钥长度越长越安全，但性能也会急剧下降。
- RSA-2048：当前业界基准线。我个人建议，在 2024 年的今天，不要用低于 2048 位的 RSA。
- RSA-3072：安全等级对标 AES-128，是中长期安全的稳妥选择。
- RSA-4096：安全冗余高，但性能开销大。除非合规强制要求，我个人觉得性价比不高。
RSA 有最大加密数据长度的限制。以 2048 位密钥为例，一次最多只能加密 245 字节。所以，永远不要用 RSA 直接加密业务数据。正确做法是用 RSA 加密临时生成的 AES 密钥，再用 AES 去加密实际数据。这叫混合加密。
ECC（椭圆曲线密码学）
ECC 是后起之秀。同样的安全强度，ECC 需要的密钥长度远小于 RSA。它的安全性基于椭圆曲线离散对数问题。
- P-256（secp256r1）：NIST 标准曲线，安全性对标 RSA-3072。兼容性最好，大部分硬件和库都支持。我个人的边界设备首选就是 P-256。
- P-384：更高安全等级，性能开销也更大。对标 RSA-7680。
- Curve25519（X25519）：设计更现代，避免了某些实现上的坑，性能更快。如果你做的是全新项目，且无需兼容旧系统，我建议直接上 X25519。
你想想看，ECC 为什么受欢迎？同样是 128 位安全强度，RSA 需要 3072 位密钥，而 ECC 只需要 256 位。密钥短了，意味着握手包更小，计算更快，存储占用也更少。这对 IoT 设备和移动端来说，优势太明显了。
密钥长度选择实战建议
密钥长度不是越长越好。我见过有人为了追求安全，所有场景都用 RSA-4096，结果设备 CPU 跑满，业务延迟飙升。你得根据场景来做权衡。
| 安全等级 | 对称加密 (AES) | 非对称加密 (ECC) | 非对称加密 (RSA) | 典型场景 |
|---|---|---|---|---|
| 基础安全 | AES-128 | P-256 | RSA-2048 | 内部网络、低价值数据 |
| 中高安全 | AES-256 | P-256 / X25519 | RSA-3072 | 互联网边界、API 网关 |
| 最高安全 | AES-256 | P-384 | RSA-4096 | 金融核心、高价值资产保护 |
核心原则：对称加密选 AES-256-GCM，非对称加密首选 ECC P-256。 如果必须兼容 RSA 老系统，至少保证 RSA-2048 起步。
性能对比：数字背后的真相
只说理论不够，我们来看真实的性能差异。下面的数据基于我去年在实验室的测试结果（CPU: Intel Xeon Gold 6258R, 开启 AES-NI）。
| 操作 | 算法 & 密钥长度 | 速度 (次/秒) | 相对耗时 |
|---|---|---|---|
| 对称加密 (1KB) | AES-128-GCM | ~2,000,000 | 1x |
| 对称加密 (1KB) | AES-256-GCM | ~1,800,000 | ~1.1x |
| 非对称加密 (签名) | RSA-2048 | ~14,000 | ~143x |
| 非对称加密 (签名) | ECC P-256 | ~70,000 | ~29x |
| 非对称加密 (验签) | RSA-2048 | ~400,000 | ~5x |
| 非对称加密 (验签) | ECC P-256 | ~25,000 | ~80x |
注意看，ECC 签名速度远超 RSA，但验签速度却慢于 RSA。所以，如果你的场景是 一次签名，多次验签（比如代码签名证书），RSA 反而有优势。如果是 实时通信密钥协商，ECC 的签名速度快，体验更好。
我再补充一点：密钥生成。ECC 密钥对的生成速度远快于 RSA。你在做密钥轮换时，这个差距会非常明显。我做过一个大规模 IoT 设备接入的项目，设备通过 ECC 生成密钥对几乎无感，如果换成 RSA，每次轮换都会让设备卡顿几秒钟。
本章核心知识结构
让我用一张图把这一章的逻辑串起来。从业务场景出发，最后落到密钥长度的选择。
这张图把整个加密选型的逻辑串在了一起。从左到右，从上到下。先分清对称和非对称的职责，再用混合加密把它们组合起来，最后根据安全等级确定具体的密钥长度。
在实际的边界架构中，你写代码时通常不需要直接处理 AES 或 RSA 的底层实现。OpenSSL、BoringSSL、以及各语言的标准库都封装好了。你需要关注的是：你选的库是否支持你需要的曲线和模式？是否启用了硬件加速？
这一章的内容就到这。记住，加密是边界安全的基础，但只是基础。后面的章节，我们会把这些算法组装起来，构建真正的密钥边界。