加密传输的核心概念：对称与非对称加密
说到加密传输，很多人第一反应就是“把数据变成乱码”。嗯，这没错。
但做审计日志传输这么多年，我发现一个现象：不少人搞不清对称加密和非对称加密到底有什么区别。说白了，就是不清楚什么时候该用哪个。
我刚开始做安全架构时也踩过坑。有一次给一个日志采集系统配加密，图省事全用了对称密钥，结果密钥分发成了灾难——几十台采集器都得手动部署同一个密钥文件，想想都头疼。
对称加密：一把钥匙开一把锁
对称加密是最直观的。加密和解密用同一把密钥。
你想想看，就像你家里的大门钥匙——锁门和开门用的是同一把。速度快，开销小，适合大量数据的实时加密。
常用算法有这些：
- AES（Advanced Encryption Standard）—— 目前最主流，我项目里90%的场景都用它
- ChaCha20 —— 移动端或性能敏感场景，Google 的 QUIC 协议也在用
- DES / 3DES —— 太老了，别用了，除非你在维护遗产系统
我的习惯：审计日志这种持续流式数据，我优先选 AES-256-GCM。它自带认证标签，能防篡改，省得你额外做 HMAC。
非对称加密：公钥锁、私钥开
非对称加密就有点意思了。它用一对密钥：公钥和私钥。公钥可以公开分发，私钥自己藏好。
你可以把公钥想象成一把挂锁——谁都能拿到，锁上之后只有你的私钥能打开。反过来，你用私钥签名，别人用公钥验证——这就是数字签名的原理。
常见的算法：
- RSA —— 经典但慢，密钥越长越安全（至少2048位）
- ECC（椭圆曲线）—— 更小的密钥长度获得同等安全，比如256位 ECC ≈ 3072位 RSA
- Ed25519 —— 我个人非常喜欢，签名速度快，抗侧信道攻击
我曾经遇到的坑：用 RSA 做大量数据的加密，结果性能惨不忍睹。非对称加密不适合加密长数据，它更适合密钥交换和数字签名。把对称密钥用非对称加密保护起来，再用对称密钥加密实际数据——这才是正确姿势。
核心对比：到底选哪个？
我整理了一张对比表，你在做架构选型时可以对照着看。
| 维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个（共享密钥） | 2 个（公钥+私钥） |
| 速度 | 快（硬件加速支持好） | 慢（比对称慢几百到几千倍） |
| 适用场景 | 大量数据加密、流式传输 | 密钥交换、数字签名、身份认证 |
| 密钥分发难度 | 高（需要安全通道传递密钥） | 低（公钥可公开，私钥自持） |
| 典型算法 | AES, ChaCha20 | RSA, ECDH, Ed25519 |
混合加密：取长补短
实际 TLS 中是怎么做的？它用的是一种叫“混合加密”的方案。
- 握手阶段：用非对称加密协商出一个临时的对称密钥（比如通过 ECDHE 密钥交换）。
- 传输阶段：用对称加密（AES-GCM）加密所有审计日志数据。
为什么要这么麻烦？说白了就是性能和安全兼顾。非对称加密负责安全地传递密钥，对称加密负责高效地加密数据。
实践要点
- 审计日志的 TLS 加密传输，你不需要自己实现加密算法——直接用成熟的 TLS 库（OpenSSL, BoringSSL, GnuTLS）
- 但你要理解底层原理，才能正确配置：比如选用哪个密码套件（Cipher Suite）
- 我建议禁用 RSA 密钥交换，只用 ECDHE，因为它提供前向安全性
核心关系一览
下面这张图帮你理清对称与非对称加密在 TLS 中的配合逻辑。
看图中左到右的箭头，就知道 TLS 是怎么工作的了：先走非对称握手交换对称密钥，之后所有审计日志数据走对称加密传输。
给审计日志专享的建议
- 日志数据量大，一定要用对称加密来扛吞吐
- 密钥定期轮换（我一般设24小时），减少泄露影响
- 如果仅内网传输，可以只用对称加密 + 安全通道（比如 WireGuard），但 TLS 是通用标准，推荐优先使用
其实理解这些概念，对后面的实践至关重要。你配置 TLS 密码套件时，选的是 AES 还是 ChaCha20？用 ECDHE 还是 RSA 密钥交换？这些决策都依赖于你今天学到的东西。