对称加密、非对称加密与 TLS

在安全通信场景中，了解对称与非对称加密的职责划分，以及 TLS 和 Diffie-Hellman 的配合，是确保数据保密和完整的基础。

对称加密

对称加密使用同一个密钥完成加密与解密，适合处理大量数据的传输场景。常见的实现包括 AES 和 DES。它的主要优势是加解密速度快，网络带宽利用率高。

但同时也存在关键挑战：密钥必须安全地从发送方传递给接收方，只要密钥泄露，任何人都可以解密通信内容。因此，它常常与密钥协商机制搭配使用，而不是单独应用。

非对称加密

非对称加密通过生成一对密钥（公钥和私钥）来实现不同的操作：公钥可以公开，用于加密或验证签名；私钥必须保密，用于解密或签名。通常，一个密钥加密的数据需要用另一把密钥解密。

典型交互

以客户端与服务端通信为例：

1. 服务端将公钥发送给客户端。
2. 客户端用该公钥加密敏感数据并发送。
3. 服务端使用自己的私钥解密数据。

这种模式把私钥的持有权锁定在服务端，降低了密钥泄露带来的风险。

常见限制与应对措施

计算量相对较大

RSA 等非对称算法在计算开销上明显高于 AES，因此通常不用于直接加密大量业务数据。一个常见的改进是混合加密：先用非对称算法协商或保护对称密钥，再用对称算法传输实际数据。当性能要求高时，还可以启用硬件加速或专用安全模块。

私钥泄露后的风险

如果私钥泄露，攻击者可以伪装成服务端或解密历史通信。缓解办法包括使用短期会话密钥、定期轮换密钥，以及借助证书管理和密钥托管策略分散单点风险。

SSL 与 TLS

SSL 是早期的安全通信协议，TLS 则是其后续版本。现在大多数 HTTPS 连接都是基于 TLS 实现的。

TLS 的核心目标

• 身份认证：确认对方的可信度，通常通过验证服务端证书完成。
• 密钥协商：让客户端与服务端共同生成会话密钥。
• 加密传输：后续的业务流量使用对称加密执行。
• 完整性保护：确保数据在传输过程中不被篡改。

TLS 握手流程

1. 客户端发送 ClientHello，说明支持的 TLS 版本、加密套件以及随机数。
2. 服务端返回 ServerHello，选定 TLS 版本和加密套件，同时附上服务端随机数。
3. 服务端提供证书，客户端验证证书链、域名与有效期。
4. 双方执行密钥交换，现代 TLS 多使用 ECDHE 等算法生成会话密钥。
5. 协商完成后，双方基于会话密钥加密后续通信。

Diffie-Hellman 密钥交换

Diffie-Hellman 让双方在无需直接传输密钥的前提下，协商出同一个共享密钥。

1. 双方约定公开参数 p 和 g。
2. 客户端生成私有随机数 a，计算公开值 A = g^a mod p 并发送给服务端。
3. 服务端生成私有随机数 b，计算公开值 B = g^b mod p 并发送给客户端。
4. 客户端计算 K = B^a mod p。
5. 服务端计算 K = A^b mod p。
6. 由于 (g^b)^a mod p = (g^a)^b mod p，双方可得到相同的共享密钥 K。

这个共享密钥一般不会直接用作业务加密密钥，而是通过密钥派生函数进一步生成实际的密钥材料。