第2章：对称加密与非对称加密原理归纳总结
加密这事儿，说白了就是两把钥匙的游戏。
一把钥匙用来锁门，另一把用来开门。如果开锁和关锁用的是同一把钥匙，那就是对称加密。如果用的是两把不同的钥匙，那就是非对称加密。
嗯，道理就这么简单。但实际工程里，门道可深了去了。我做过好几年KMS（密钥管理服务）的架构设计，见过不少团队在这上面栽跟头。咱们今天就把这俩兄弟的底裤扒干净。
对称加密：用同一把钥匙搞定一切
对称加密的历史最久。从古罗马的凯撒密码，到现代的AES算法，核心思想都是同一个——加密和解密共用同一个密钥。
你想想看，发送方和接收方手里都拿着同一把钥匙。发送方把明文拧成密文，接收方再用同一把钥匙把密文解开。这种模式天然简单，计算速度极快。
核心特点：
- 加解密速度极快，适合大批量数据
- 密钥长度相对较短（128位~256位）
- 最大的坑：密钥分发问题。怎么安全地把这把钥匙交给对方？
我在项目中遇到过一家金融公司，他们用AES-256加密交易流水。性能完全不是问题，单机每秒能处理上百万笔。但后来出了个事故——运维人员把密钥硬编码在配置文件中，结果配置文件被不小心上传到了公共Git仓库。嗯，那一周他们加班到凌晨三点。
避坑指南：我曾经接手过一个客户的项目，他们用同一个密钥加密所有用户的敏感数据。一个用户被攻破，全盘皆输。正确的做法是每个数据对象使用独立的数据加密密钥（DEK），再通过密钥加密密钥（KEK）来保护DEK。这是分层密钥管理的基本功。
常见的对称加密算法
| 算法 | 密钥长度 | 分组大小 | 安全状态 |
|---|---|---|---|
| AES | 128/192/256 bit | 128 bit | ✅ 安全（推荐） |
| DES | 56 bit | 64 bit | ❌ 不安全（已破解） |
| 3DES | 112/168 bit | 64 bit | ⚠️ 逐步淘汰 |
| ChaCha20 | 256 bit | 流密码 | ✅ 安全（移动端常用） |
我个人习惯，现代系统首选AES-256-GCM。为什么？GCM模式自带认证加密，能同时保证机密性和完整性。省去额外做HMAC的步骤，少踩一个坑。
非对称加密：公钥私钥的哲学
非对称加密彻底解决了密钥分发问题。每个参与者都生成一对密钥——公钥公开，私钥自己藏好。
用公钥加密的数据，只有对应的私钥能解开。反过来，用私钥签名，公钥可以验证签名。这一进一出，信息安全和身份认证就全有了。
但代价是什么？速度奇慢。RSA-2048加密一个256位的AES密钥，大概需要1~2毫秒。而AES加密同样的数据量只需要几微秒。差了三个数量级。
所以实际工程里，没有人会直接用非对称加密去加密大文件。都是混合加密：用非对称加密协商一个临时的对称密钥，再用对称密钥加密真正的数据。这就是HTTPS的底层逻辑——TLS握手过程中的密钥协商。
个人经验：我在设计KMS系统时，习惯将非对称密钥对分为两种用途：
- 加密用途：公钥加密数据，私钥解密。适合数据保护。
- 签名用途：私钥签名，公钥验签。适合身份验证和不可否认性。
千万别用同一对密钥既做加密又做签名。前者需要长期保存私钥，后者需要频繁使用私钥。混在一起会大大提高私钥泄露的风险。
主流非对称算法对比
| 算法 | 密钥长度（安全等级） | 主要用途 | 安全状态 |
|---|---|---|---|
| RSA | 2048/4096 bit | 加密、签名 | ✅ 安全（2048位及以上） |
| ECC（椭圆曲线） | 256 bit ≈ RSA 3072 | 加密、签名、密钥协商 | ✅ 安全（推荐） |
| DSA | 1024/2048 bit | 仅签名 | ⚠️ 不推荐（有安全争议） |
| Ed25519 | 256 bit | 签名（高性能） | ✅ 安全（新兴标准） |
我个人强烈推荐ECC系列。同样的安全强度，ECC的密钥长度只有RSA的十分之一。这就意味着更短的证书、更快的运算、更少的带宽。你想想看，在IoT设备上跑RSA-4096，芯片都得冒烟。但跑P-256曲线，轻轻松松。
// OpenSSL生成ECC密钥对示例
// 私钥：ec-private-key.pem
// 公钥：ec-public-key.pem
// 生成私钥
openssl ecparam -genkey -name prime256v1 -out ec-private-key.pem
// 从私钥导出公钥
openssl ec -in ec-private-key.pem -pubout -out ec-public-key.pem
// 查看密钥详情
openssl ec -in ec-private-key.pem -text -noout对称 vs 非对称：一张表说清楚
| 维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1个（共享密钥） | 2个（公钥+私钥） |
| 加解密速度 | 极快（硬件加速可达10+ Gbps） | 慢（通常慢100~1000倍） |
| 密钥分发 | 难（需要安全通道传递密钥） | 易（公钥可直接公开） |
| 主要用途 | 批量数据加密 | 密钥交换、数字签名、证书 |
| 典型算法 | AES, ChaCha20, SM4 | RSA, ECDSA, SM2 |
| 安全基础 | 密钥的保密性 | 数学难题（大数分解、离散对数） |
混合加密：现实世界的最佳实践
你想想看，如果只用对称加密，密钥怎么安全传输？如果只用非对称加密，性能怎么扛得住？
所以现实世界里，没人会二选一。都是混合着来。
举个例子：你给朋友发送一份加密文件。
- 你随机生成一个256位的AES密钥（叫它会话密钥）
- 用这个AES密钥加密你的大文件
- 用朋友的公钥（RSA或ECC）加密那个AES密钥
- 把加密后的文件 + 加密后的会话密钥一起发给朋友
- 朋友用自己的私钥解开会话密钥
- 朋友用会话密钥解密文件
这个过程，完美结合了两者的优势。非对称加密解决密钥分发，对称加密解决数据加密效率。我参与设计的KMS系统里，所有数据加密密钥（DEK）都是用这种方式保护的。
注意：千万不要用同一个会话密钥加密多个文件。每次加密操作都应该生成新的随机密钥。在云KMS里，每次调用GenerateDataKey都会返回一个全新的DEK，这是标准做法。
密钥边界的核心问题
好了，现在你知道了这两种加密方式。那么问题来了：这些密钥应该存在哪里？谁能访问？用完之后怎么销毁？
这就是《密钥边界权限模型》要回答的核心问题——密钥的边界在哪里？是内存里？是硬件安全模块（HSM）里？还是云服务的密钥管理服务（KMS）里？
不同的边界，决定了不同的安全等级和性能开销。
密钥边界的三个层次：
- 应用层边界：密钥在应用程序进程内存中。速度快，但攻击面大。
- 进程外边界：密钥在独立的密钥管理服务中。隔离性好，但有网络延迟。
- 硬件边界：密钥在HSM或TEE中。安全等级最高，但成本也最高。
记住一句话：密钥在哪里，边界就在哪里。边界决定了攻击者要跨过多大的坎才能拿到密钥。咱们后续的章节会深入讲这个模型，包括细粒度的权限控制、密钥的轮转策略、以及审计日志的设计。
这张图能帮你快速理清思路。左侧是对称加密模型，发送方和接收方共享同一个密钥。右侧是非对称加密模型，公钥人人可得，私钥只保存在接收方手里。
记住，没有哪种加密方式是完美的银弹。对称加密和非对称加密各有所长，结合起来才能构建真正安全高效的密码体系。往后咱们要深入细粒度权限模型，每一步都离不开这些底层理解。