3. 加密技术基础：对称加密与非对称加密归纳总结
聊加密之前，先问个问题：你在项目里用什么加密？我见过不少团队直接一把梭「RSA-2048」，结果加解密慢得离谱。说实话，没有万能密码术，只有适合场景的方案。
这一章咱们把对称加密和非对称加密掰开揉碎讲清楚。我的目标很简单：让你下次选加密时，脑子里马上能浮现一张「地图」——哪个场景该用谁，怎么搭着用。
3.1 对称加密：一把钥匙开一把锁
对称加密，说白了就是加密和解密用同一把密钥。你想想看，像你家大门钥匙——锁门和开门都用同一把，简单直接。
- 核心逻辑：
Cipher = Enc(Plaintext, Key)，Plaintext = Dec(Cipher, Key) - 代表算法：AES、SM4、3DES（别用了）、ChaCha20
- 优势：速度快，硬件支持好（AES-NI指令集）
- 短板：密钥分发难，N个人通信就得N×(N-1)/2把密钥
我的习惯：在DSPM密文检索场景里，我几乎只用AES-256-GCM。为什么？因为明文被加密后还要做检索索引，GCM模式自带认证，省去额外MAC开销。之前有个项目用AES-CBC，结果被填充预言攻击搞了一个漏洞，修起来巨痛苦。
3.2 非对称加密：公钥公开，私钥保密
非对称加密是个更巧妙的玩法。每个用户生成一对密钥：公钥随便发，私钥自己藏。别人用你的公钥加密，只有你能用私钥解密——解决了对称加密的密钥分发死结。
- 数学原理：依赖大数分解（RSA）、椭圆曲线离散对数（ECC）等单向陷门函数
- 代表算法：RSA、ECC（ECDSA/ECDH）、SM2、Ed25519
- 优势：密钥管理方便，支持数字签名和密钥交换
- 短板：性能慢（比对称加密慢2~3个数量级），且密文会膨胀
避坑：我曾经见过有人直接用RSA加密大块数据（比如几MB的文件），结果程序跑了几十秒才加密完。记住：非对称加密永远只适合加密小数据（密钥、哈希值），大数据必须用对称加密。
说到密钥长度，我习惯做一张表留档，方便团队评审时快速对照：
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个密钥 | 一对（公钥+私钥） |
| 速度 | 极快（>1 GB/s） | 慢（~100 KB/s 量级） |
| 安全强度（等价） | AES-128 ≈ RSA-3072 ≈ ECC-256 | 依赖具体算法 |
| 典型场景 | 大数据加密、全盘加密 | 密钥交换、数字签名、证书 |
| 常见算法 | AES, SM4, ChaCha20 | RSA, ECC, SM2, Ed25519 |
3.3 实践中的混合加密：博采众长
现实项目里没人会只选一种加密。最经典的组合就是「混合加密」：用非对称加密传递对称密钥，然后用对称密钥加密实际数据。你每天用的HTTPS就是这么干的。
我在做DSPM审计日志传输时，也用了这个套路：
- 客户端生成一个随机的AES-256密钥（会话密钥）
- 用服务端的RSA公钥加密这个AES密钥
- 将加密后的AES密钥和用AES加密的日志数据一起发过去
- 服务端用私钥解开AES密钥，再用它解密日志
这样做的好处是：既利用了对称加密的速度，又避开了密钥分发的难题。非对称加密只处理一个极小的密钥块，性能瓶颈可以接受。
核心结论：在密文检索这个课程主题里，你要记住——
- 明文索引用对称加密（AES-SIV，保留可检索性）
- 密钥分发和身份认证靠非对称
- 混合加密是工程标配，不要自己发明协议
3.4 知识体系图
下面这张图把对称、非对称、混合加密的脉络串起来了。你可以把它当作「加密选型走查表」存手机上。
3.5 避坑清单（都是血泪教训）
- 密钥长度别偷懒：AES至少128位（256更好）；RSA至少2048位；ECC至少256位。我曾经见过生产线用RSA-512的扫描仪固件……一周就被破解了。
- 随机数一定要真随机：
random.randint生成的密钥等于没用。项目中我强制要求用secrets._bytes(32)或系统的/dev/urandom。 - 不要自己拼协议：直接用TLS或COSE标准。我早年做过一个混合加密，自己发明了「先签名再加密」的糟心顺序，后来发现早就有人踩过这个坑。
- 算法不要硬编码：保留算法协商机制。DSPM审计日志需要长期存储，未来可能需要迁移到抗量子加密。
嗯，加密基础先到这里。什么场景用什么，心里有谱了就好。后面咱们会把这些技术具体用到密文检索的审计日志架构里。到时候你再回头翻这张图，会发现所有设计都围绕一个核心：用对称加密解决效率，用非对称加密解决信任。