2. 常见加密算法与协议
加密算法这东西，说白了就是给数据加把锁。锁的材质不同，开锁的方式也不同。这一章我会带你过一遍最常用的几种——对称加密、非对称加密、哈希算法，以及怎么用TLS把这些锁串起来。
2.1 对称加密：AES
对称加密，就是加密解密用同一把钥匙。优点很明显——速度快。缺点也直接——怎么安全地把钥匙给到对方？
AES是目前最主流的对称加密标准。我个人习惯优先选择AES-256，虽然比AES-128慢一点点，但安全余量更足。曾经有一次项目中客户要求使用国密SM4，但对接的第三方只支持AES，最后我建议客户统一用AES-256，通过专线传输密钥，既满足合规也避免了两边扯皮。
AES的核心参数：
- 密钥长度：128、192、256位。256位是当前推荐值。
- 工作模式：ECB不安全，千万别单独用。CBC需要IV，GCM内置认证，我基本只用GCM。
- 填充方式：GCM模式不需要填充，CBC模式常用PKCS7。
2.2 非对称加密：RSA与ECC
非对称加密解决了一个核心问题：钥匙怎么安全传递。公钥公开，私钥私藏。用公钥加密的数据，只有私钥能解。
但在实际项目中，大家很少直接用非对称加密大批量数据——太慢了。常规做法是用非对称加密交换对称密钥，再用对称密钥加密业务数据。这就是混合加密机制，TLS就是这么干的。
RSA与ECC对比：
| 特性 | RSA | ECC (如ECDSA/ECDH) |
|---|---|---|
| 安全性基础 | 大整数质因数分解 | 椭圆曲线离散对数 |
| 密钥长度推荐 | 2048位以上 | 256位（等价于RSA 3072位） |
| 性能 | 加解密较慢 | 签名更快，密钥交换效率更高 |
| 典型应用 | 数字证书、密钥封装 | 移动端、IoT设备 |
我个人的经验是：大多数服务端通信场景用RSA 2048位就够了，兼容性好，几乎所有TLS库都支持。但如果你的项目有移动端或者低功耗设备，ECC会更好，因为同等安全强度下密钥短、计算快。
为什么会这样？你想想看，RSA依赖大数运算，2048位的密钥做一次签名，CPU得算很久。而ECC用256位的密钥就能达到相近的安全级别，性能优势明显。
2.3 哈希算法：SHA-256
哈希算法不是用来加密的，它是用来做“指纹”的。输入任意长度的数据，输出固定长度的摘要。而且理论上，无法从摘要反推原文。
SHA-256是当前最稳妥的选择。MD5和SHA-1已经不再安全，不要再用了。我记得三年前一次渗透测试，对方直接用彩虹表碰撞了系统中存储的MD5密码，好在那套系统只是内部演示环境，不然后果很严重。
哈希算法在加密接口中的典型用途：
- 数据完整性校验：对消息做哈希，接收方重新计算并比对。
- 密码存储：加盐后存储SHA-256哈希值。
- HMAC：结合密钥的哈希函数，用于接口签名认证。
2.4 TLS协议基础
TLS，就是HTTPS里那个S，它是把对称加密、非对称加密、哈希算法串起来的“胶水”。
TLS握手的关键步骤：
- 客户端问候： 支持的TLS版本、密码套件列表、随机数。
- 服务器问候： 选定的TLS版本、密码套件、数字证书、随机数。
- 证书验证： 客户端验证服务器证书的合法性。
- 密钥交换： 使用非对称加密（如RSA或ECDHE）协商出一个预主密钥。
- 会话密钥生成： 双方用预主密钥和随机数生成对称加密密钥。
- 加密通信： 后续数据使用AES-GCM等对称加密传输。
嗯，这里要注意：TLS 1.2和TLS 1.3有较大差异。1.3简化了握手流程，减少了一次往返，同时废弃了大量不安全的密码套件。如果你在配置新系统，建议直接切换到TLS 1.3。
最后，我习惯用一张图来理解这四类技术的关系：
你看这张图就明白了。对称加密、非对称加密、哈希算法是三个基础模块，TLS协议把它们有机组合起来，最终形成安全的加密通信信道。