对称加密与非对称加密：原理、选型与工程实践

1. 项目概述与核心思路拆解

1.1 加密是什么，我为什么会研究这个

先聊聊我为什么会专门写一篇关于对称加密和非对称加密的文章。这几年做后端开发，接触过的系统和数据链路越来越多，发现一个很现实的问题：很多开发者对加密的理解停留在“用现成的库调一下接口”的层面。代码能跑起来，数据也确实加密了，但问一句“你用的什么模式？”“为什么这里要用非对称加密而不是对称加密？”往往就答不上来了。

这不怪大家，因为加密这东西平时确实不容易直接“看见”效果。你往数据库里存密码，用了哈希，看不出有什么变化；你调接口传数据，加了HTTPS，也感觉不到加密过程。但一旦出了安全事故——数据库泄露、数据被篡改、密钥被拿到——回过头来才发现，很多问题根源就是当初对加密方案的选型和使用不当。

我研究这个主题，就是想把这些年踩过的坑、总结出来的经验一次性说清楚。这篇文章会讲清楚对称加密和非对称加密各自的设计思路，它们分别解决什么问题，实际工程中怎么组合使用，以及我在真实项目里遇到过的典型问题和排查过程。

1.2 两种加密解决的核心问题完全不同

先上一个最直观的结论：对称加密解决的是“高效加密大数据”的问题，非对称加密解决的是“安全交换密钥”的问题。这两句话一定要先记住，后面的所有内容都是围绕这两句话展开的。

为什么这么说？对称加密的特点是加密和解密使用同一把密钥，速度快、效率高，适合加密大块数据。但它有一个致命缺陷：如果通信双方远隔千里，怎么把这把密钥安全地送到对方手里？如果密钥在传输过程中被截获，那整条加密通道就形同虚设了。这就是所谓的“密钥分发问题”。

非对称加密恰好解决了这个问题。它使用一对公私钥，公钥可以公开分发，私钥自己妥善保管。发送方用接收方的公钥加密，只有持有对应私钥的接收方才能解密。这样就不需要提前共享密钥了。但非对称加密的计算开销远大于对称加密，不适合加密大数据量内容。

这两种加密方式本质上是一对互补的组合，把两者结合起来，用非对称加密来安全地协商对称密钥，再用对称密钥加密的实际传输数据。这是HTTPS、SSH等几乎所有现代安全协议的核心设计思路，也是整个密码学工程应用中最重要的一环。

1.3 在动手之前，先建立两张“地图”

要真正理解加密，先把两个基础概念挂上钩：加密算法和加密模式。

加密算法是具体的数学变换规则，比如AES、RSA。加密模式则是在算法基础上定义“怎么把明文拆成块、块之间如何关联”的策略。举个生活化的例子：算法像是包饺子的手法——捏褶子、封口；模式则像是排饺子入锅的顺序——是从外围开始下，还是从中间下，下完之后要不要互相粘连关联。手法相同但排列策略不同，煮出来的效果和安全性都不一样。

我会在正文中用大量篇幅拆解这两部分。先给读者一张总览表：

这张表是骨架，后面的章节全都围绕它展开。搞清楚了这张表背后的原理和取舍，你就能在真实项目中清楚地判断：这段链路该用对称加密还是非对称加密，或者两者怎么搭配。

2. 对称加密的深入解析：从原理到实操

2.1 对称加密的核心思想与第一个坑

对称加密又叫私钥加密、单钥加密。它的核心就一句话：发送方和接收方共享同一个密钥，加密和解密用的是同一把钥匙。你可以把它想象成一个带锁的保险箱，锁孔只有一个，你跟对方各配一把完全相同的钥匙，谁拿到钥匙谁就能开箱取物。

这个直观模型背后藏着的设计难点是密钥配送。远古时代人们传密信，用密码本，但密码本怎么安全送到对方手里？在现代网络环境中，密钥不可能走物理渠道递送，在网上传密钥本身就可能被截获。所以对称加密单独使用时，最大的问题不是算法不够强，而是“密钥怎么安全共享”。

我在初学阶段踩过第一个大坑：在某项目里直接用AES加密传输数据，密钥写死在前后端代码里。表面上看数据是密文传输，可一旦攻击者拿到前端代码（前端代码本来就等于是公开的），密钥就直接暴露了，加密形同虚设。

正确的做法，密钥必须通过安全的渠道协商出来，最典型的就是让非对称加密来完成这个任务。对称加密负责的是“协商好密钥之后”的加密通信阶段。如果你直接在业务代码里写死对称密钥，相当于把保险箱的钥匙贴在保险箱旁边，搞笑且致命。

2.2 AES算法：现代对称加密的绝对主力

AES（Advanced Encryption Standard）是目前使用最广泛的对称加密算法。它是美国国家标准与技术研究院公开征选最终胜出的算法，由比利时密码学家所设计，原名Rijndael。AES取代了早年的DES算法，因为DES的56位密钥在现代计算能力下已经被证明不够安全。

AES的三个关键参数：

三次AES迭代中，每一轮都有四个核心操作：字节代换（SubBytes）、行移位（ShiftRows）、列混合（MixColumns）和轮密钥加（AddRoundKey）。字节代换通过S盒（Substitution-box，一个预定义的256字节置换表）做非线性替换，这是抵御现代密码分析的关键。行移位和列混合则是把数据在整个16字节块内扩散，让明文的微小改动迅速扩散到整个密文块。

用生活类比解释：AES的加解密过程就像把16个数字写在一个矩阵里，先按密码本（S盒）逐字替换，再把行顺序打乱，接着把列混合搅拌，最后跟轮密钥做异或。经过10到14轮这样的操作，哪怕明文里只有一个比特的变化，也会像雪崩一样扩散到整个加密结果中，密文看上去跟随机数没什么区别。

2.3 工作模式：ECB、CBC、CTR、GCM该怎么选

这是我在实操中见过最多人踩坑的地方。AES算法定义了如何处理一个128位分组，但实际数据几乎不可能正好是16字节的整数倍，而且多个分组之间如果独立加密，会暴露明文的统计模式。这时候就需要“工作模式”来定义分块处理策略。

ECB模式（电子密码本模式）：最简单，每个分组独立用密钥加密。缺点极其明显：相同的明文分组必然产生相同的密文分组，专业术语叫“模式泄露”。我用一张著名的企鹅图来举例——明明加密了，但密文图片的轮廓仍然清晰可见，因为图像中相同颜色区域的加密结果也相同，图案信息完全暴露。这在实际项目中是绝对不能用的，除非是加密单个独立且无规律的数据块，比如加密一把随机生成的密钥。

CBC模式（密码分组链接模式）：每个明文分组先与上一个密文分组做异或，然后加密，第一个分组异或的是一个随机初始向量（IV）。这样即使两个明文分组完全相同，产生的密文分组也不同，有效掩盖了模式信息。CBC是历史上最常用的模式，但它有几个痛点：加密过程只能串行，无法并行处理；如果某一块密文在传输中损坏，会影响当前块和下一块的解密。

CTR模式（计数器模式）：设计思路完全改变，把分组加密变成一个流密码。用一个递增计数器作为输入，加密后得到密钥流，再跟明文分组做异或。最大的优点是可以并行加密，性能极好，需要解密时同样只需计算密钥流做异或。缺点也和所有流密码一样，密钥流绝对不能重复使用，否则异或结果会泄露明文信息。

GCM模式（伽罗瓦计数器模式）：这是我最推荐在实际工程中使用的模式。它本质上是CTR模式加上GMAC认证。也就是说，GCM在加密的同时会生成一个认证标签（tag），解密时校验这个标签，确保密文没有被篡改过。这解决了加密和认证分离的老问题——很多旧的系统用CBC加密、另外用HMAC做认证，一旦配合不当就可能被攻击者插入恶意密文。

我的选型建议很简单：新项目统一用AES-256-GCM，旧项目若还在用CBC模式，尽快迁移。GCM模式同时提供保密性、完整性和真实性，一份工作干三份，代码也简洁，不需要自己拼接HMAC。

2.4 填充方式：PKCS7与NoPadding的适用场景

解决了模式问题，还有一个躲不开的细节：填充。AES是分组密码，128位分组意味着每次加密16字节，但实际数据往往长短不一。比如加密一段JSON字符串，假设长度是30字节，塞进两个16字节分组后还差2字节，怎么办？这时就需要填充。

业界使用最广泛的是PKCS7填充。规则是：需要填充n字节，就补n个值为n的字节。例如差2字节，就补两个0x02；差7字节，就补七个0x07。如果明文长度恰好是16的整数倍，PKCS7会额外补满一整个16字节的0x10块，防止解密时无法区分“真实内容”和“末尾填充”。

还有NoPadding，就是不填充，要求明文长度必须刚好是16的倍数。实际业务里基本不会有人去手动控制数据长度，所以NoPadding极少用。但有一个例外是RSA加密时常选NoPadding配合OAEP填充逻辑，那是因为RSA的分组大小固定且内部有特殊填充，跟AES的PKCS7不在一个层面。

实操时最容易犯的错误是：一端用了PKCS7填充，另一端解密时用了NoPadding，或者两端填充逻辑不一致，结果解密下来的数据末尾多出一串奇怪的字符。排查起来非常隐蔽，因为解密接口可能不会直接报错，只是数据莫名其妙地多了一段内容。

2.5 AES+GCM实操：用Python代码实现一次完整加解密

为了直观感知对称加密的完整流程，我写一个Python示例。使用 cryptography 库，这是一个成熟的第三方密码学库，比直接操作openssl命令行友好得多。

from cryptography.hazmat.primitives.ciphers.aead import AESGCM import os # 生成256位密钥（32字节） key = AESGCM.generate_key(bit_length=256) aesgcm = AESGCM(key) # 重要：nonce（即IV）必须每次不同，且不可重复使用 nonce = os.urandom(12) # GCM推荐12字节 plaintext = b"这是需要加密的敏感数据" # 加密 ciphertext = aesgcm.encrypt(nonce, plaintext, None) print("密文:", ciphertext.hex()) # 解密 decrypted = aesgcm.decrypt(nonce, ciphertext, None) print("解密结果:", decrypted.decode())

这个例子中，encrypt方法会返回密文，解密时同样接收nonce和密文，如果密文被篡改，decrypt会直接抛出异常，这是GCM的认证特性在起作用。

实际使用有几个关键点：

• nonce千万不能复用。假设你用同一个key加密了两条不同明文，nonce又相同，攻击者可以直接通过异或操作推导出两条明文的关系，等于给攻击者开后门。一般建议nonce用随机数生成，且长度至少12字节。
• 密钥管理需要单独设计，不能把key直接放在代码里。真实项目中，key应该从密钥管理系统加载，比如云上的密钥托管的服务，或者至少放在环境变量中，并配合权限管控。
• 密文和nonce如何传输：常见做法是把nonce和密文拼接在一起发给对方，比如nonce + ciphertext。因为nonce本身不是机密信息，不需要保密，只需要保证唯一性。

我用这个模式在多个项目里落地过，实测下来性能很好，加解密一次KB级别的数据在毫秒范围内完成，且在数据完整性校验上省了大量额外代码。如果你之前用的是CBC+HMAC的方案，我强烈建议换成AES-GCM。

2.6 对称加密的软肋：密钥管理问题

对称加密原理简单、性能优秀，但绕不过去的坎始终是密钥管理。如果密钥泄露，一切加密工作都白费。而且实际项目里，密钥不止一把，可能每个服务、每个环境、每个租户都要有不同的密钥。怎么生成、怎么分发、怎么轮换、怎么撤销，是个复杂工程问题。

一些务实的建议：

• 密钥生成必须使用密码学安全随机数生成器，不要用普通的伪随机数函数，更不要用时间戳做种子。
• 密钥尽量不出内存、不入日志。打印调试信息时注意不要把密钥变量打出来，这种失误在真实事故中屡见不鲜。
• 建议设置自动轮换机制，比如每90天换一次密钥。轮换时还要考虑旧数据的解密，所以最好在数据中标识密钥版本。
• 别自己设计密钥管理协议。如果条件允许，直接用成熟的云厂商密钥管理服务或者自建专门的管理组件，它负责加解密权限控制、密钥轮换、审计日志等。

我再强调一次，对称加密本身并不复杂，复杂的是它周围密钥管理的整套体系。很多安全事件追溯根因，并不是加密算法被攻破了，而是密钥在生成、存储、传输的某个环节出了问题。

3. 非对称加密：公钥与私钥的数学魔法

3.1 核心原理：单向陷门函数

如果对称加密像是一把锁配两把相同的钥匙，那非对称加密就更像一个特殊的信箱：任何人都可以往信箱里投信（公钥负责加密），但只有信箱主人手里的钥匙才能打开箱门取信（私钥负责解密）。公钥是公开的，谁都能看；私钥是保密的，只有持有者知道。

这套机制之所以能成立，靠的是数学上的一类特殊函数——单向陷门函数。通俗地说，这类函数正向计算很容易，反向计算极其困难；但如果知道一个“陷门信息”（即私钥），反向计算就变得容易。

RSA算法基于的具体难题是“大整数分解”。两个大素数相乘，得到一个大合数很容易；但反过来，从一个大合数分解出两个素数因子则极其困难。以现在公认的RSA-2048为例，这个合数有617位十进制数字，即便用顶尖的超算去暴力分解，也需要远超人类文明的时间尺度。

我不建议读者去深究数论证明细节，但要理解RSA的运作逻辑，动手推一遍密钥生成是最有效的。

3.2 RSA密钥生成：手把手推一遍

以一组极小的参数来演示RSA密钥生成过程，帮你建立直觉。实际工程中这些数字是几百位的大数，但步骤一模一样。

第一步：选择两个大素数p和q。举例：取p=61，q=53。真实场景中p和q都必须是随机生成的大素数，且不能太接近，否则容易被因数分解算法攻击。

第二步：计算n = p*q。n = 61*53 = 3233。n就是公钥和私钥中都包含的模数。它的二进制长度决定了密钥长度，所以RSA-2048表示n是一个2048位的整数。

第三步：计算欧拉函数φ(n) = (p-1)*(q-1)。φ(3233) = 60*52 = 3120。欧拉函数在密钥生成中的意义是，后续选取的指数必须与φ(n)互质，才能保证加密解密变换可逆。

第四步：选择公钥指数e。要求e与φ(n)互质，且1 < e < φ(n)。常用取值是65537，因为它是一个较大的素数，与大多数φ(n)互质，且二进制表示中只有两个1，计算效率高。本例取e=17。

第五步：计算私钥指数d，满足 e*d ≡ 1 (mod φ(n))。这等价于解一个模逆元方程。用扩展欧几里得算法可以求出d，本例中d=2753，因为 172753 = 46801，而46801 = 153120 + 1，所以17*2753 ≡ 1 (mod 3120)。

最终公钥是(n, e)即(3233, 17)，私钥是(n, d)即(3233, 2753)。加密时计算 c = m^e mod n，解密时计算 m = c^d mod n。如果别人只知道公钥(n, e)，在没有私钥d的情况下，唯一的破译路径就是分解n得到p和q，从而算出φ(n)和d。这就是RSA安全性的数学基石。

我在实际项目里不会自己生成RSA密钥，都是直接用命令行工具或者库函数生成。但手工推过一遍之后，对密钥长度、公钥指数、私钥长度之类参数的理解会完全不同，排错时思路也清晰得多。

3.3 加密 vs 签名：两种截然相反的操作

非对称加密有一个让很多新手困惑的点：公钥和私钥不是简单“公钥加密、私钥解密”这一种用法，还可以反过来用——私钥签名、公钥验签。

这两种操作解决的是完全不同的安全目标。加密的目标是“保密性”，确保只有私钥持有者能读；签名的目标是“真实性和不可否认性”，确保消息确实来自某个私钥持有者，并且没有被篡改。

可以这样记：

实际项目中，RSA加密使用率其实不算太高，因为RSA加密大数据的性能很差。更常见的用途是数字签名。比如软件发布时的签名校验、JWT令牌的签名、区块链交易的签名，都走的是“私钥签名、公钥验签”的路线。

我在某项目里就遇到过一个经典误解：有人试图用私钥加密一段数据，然后把公钥给别人解密，以为这样也能保密。这个思路是错的。公钥是完全公开的，谁都能拿到，等于任何人都能解密这段数据，保密性完全丧失。加密必须用接收方的公钥，必须搞清楚方向和角色。

3.4 填充机制：不要用PKCS#1 v1.5，尽量用OAEP

RSA加密一个容易出问题的细节是填充模式。RSA本身是确定性算法——同样的明文、同样的密钥，得到的密文一定相同。如果直接对明文进行模幂运算，攻击者可以通过选择明文攻击来判断解密内容。所以RSA在实际使用中必须加填充。

最常见的两个填充方案：

• PKCS#1 v1.5填充：历史很长，实现简单，但被证明存在侧信道攻击风险，例如著名的Bleichenbacher攻击，攻击者可以利用解密时的填充错误响应逐步恢复明文。现在主流安全标准已经不建议在新的系统中使用。
• OAEP填充（最优非对称加密填充）：引入了随机性，即使同一明文多次加密，每次密文都不同。它通过两个哈希函数和掩码生成函数构造，被证明在随机预言机模型下是安全的。推荐使用。

我在代码中实践时，用Python的cryptography库可以很方便地选择OAEP。

from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import hashes # 生成2048位RSA密钥对 private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) public_key = private_key.public_key() message = b"这是一段需要加密的消息，但由于RSA性能限制，通常只用于加密短小数据" ciphertext = public_key.encrypt( message, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) ) plaintext = private_key.decrypt( ciphertext, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) ) print(plaintext.decode())

注意RSA-2048一次最多能加密的数据长度是有限的。因为模数是2048位，就是256字节，减去OAEP填充开销，用SHA-256时大概只能加密190字节左右。所以RSA从来不是用来加密大数据的。

那大的数据怎么办？这就引出了下一章的混合加密方案。

3.5 ECC与RSA的对比：为什么新一代协议偏爱椭圆曲线

这一节简单谈谈椭圆曲线密码学（ECC），因为它在现代协议中越来越重要。ECC基于椭圆曲线离散对数难题，数学结构比RSA更复杂，但核心优势很明显：同样安全强度下，ECC的密钥短很多、运算快很多、带宽占用小很多。

比如128位安全强度，RSA需要3072位密钥，而ECC只需要256位。这就是为什么现代TLS协议越来越倾向于使用ECC系列算法：握手数据更小，移动设备计算更快，安全性还更高。

ECC常用的曲线包括P-256（prime256v1）、P-384等，以及更注重性能的X25519曲线。实际使用中，密钥生成和签名验签的性能指标都非常优秀，我实测过用P-256做签名比用RSA-2048快一个数量级。

但ECC也有自己的坑：曲线参数选择非常敏感，永远不要自己发明曲线或参数，直接用标准曲线。曾经有厂商在自家产品里用自造的椭圆曲线参数，后来被证明存在后门漏洞，导致大量设备受影响。这个教训在密码学领域反复出现过很多次。

4. 混合加密体系：工程实践中的黄金搭档

4.1 为什么实际系统几乎都用混合加密

前面提到了对称加密性能好但密钥分发难，非对称加密解决了密钥分发问题但性能差。实际工程当然不会做二选一，而是把两个结合到一起，这就是混合加密体系。

流程可以概括为：先通过非对称加密安全协商出一个临时对称密钥（通常叫会话密钥），之后所有业务数据都用这个对称密钥加密传输。这样既解决了密钥分发问题，又保证了大数据量加解密的效率。

举一个最经典的落地案例——HTTPS。你访问任何一个HTTPS网站时，浏览器和服务器之间自动完成了这样一套混合加密协商过程。这也是为什么TLS被誉为“现代互联网安全的基石”。

4.2 一次TLS握手拆解：混合加密到底做了什么

TLS握手过程有个缩写：TLS握手协议。简化版的流程如下：

1. 浏览器发起连接，携带支持的加密套件列表、TLS版本、随机数等。
2. 服务器回复自己的证书（包含公钥）、选择一个加密套件、返回自己的随机数。
3. 浏览器验证证书的合法性，确认公钥确实属于该服务器。
4. 浏览器使用服务器公钥，以某种密钥交换算法（例如ECDHE）协商出预主密钥。
5. 双方各自用预主密钥和两个随机数推导出会话密钥。
6. 之后所有数据都使用对称加密（AES-GCM等）进行保护。

这里有两个关键点值得展开。

证书验证：浏览器为什么信任那个公钥？靠的是数字证书体系。服务器证书由受信任的证书颁发机构（CA）签名，浏览器内置了这些CA的根证书。CA用其私钥对服务器公钥等信息签名，浏览器用CA的公钥验签，从而确认客户端拿到的公钥确实没被中间人替换。这就是非对称加密的“签名”能力在基础设施层面的应用。

密钥交换方式：现代TLS常选用ECDHE（椭圆曲线 Diffie-Hellman密钥交换）实现“前向保密”。这意味着即使服务器长期私钥将来泄露，攻击者也无法回推过去的会话密钥，之前截获的密文不会被解密。这个特性非常关键。而如果你使用的是静态RSA密钥交换，一旦服务器私钥泄露，所有历史流量都能被解密，后果不堪设想。

可以看到，一条完整的HTTPS链路中，非对称加密承担了身份认证、密钥协商，对称加密承担了大流量加解密，两者各司其职。这正是工程上最经典的分工模式。

4.3 实操：设计一套完整的接口数据加密方案

用一个小型C/S架构的API通信场景做演示。假设有一个客户端App和一个后端服务，需要保证API传输数据的机密性和完整性。我会设计并实现一套简化版的混合加密方案。

流程设计如下：

1. 服务端生成RSA密钥对，公钥内置在客户端App中（或通过安全渠道下发）。
2. 客户端每次会话开始时，生成一个随机的AES-256-GCM密钥（即会话密钥）。
3. 客户端用服务端RSA公钥加密这个会话密钥，把加密后的会话密钥发给服务端。
4. 服务端用RSA私钥解密得到AES会话密钥。
5. 后续所有业务请求和响应都用这个AES密钥进行GCM加密传输。

用Python演示核心代码：

# ---------- 服务端 ---------- from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.ciphers.aead import AESGCM import os server_private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) server_public_key = server_private_key.public_key() # ---------- 客户端 ---------- # 1. 生成会话密钥 session_key = AESGCM.generate_key(bit_length=256) # 2. 用服务端公钥加密会话密钥 encrypted_session_key = server_public_key.encrypt( session_key, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) ) # 此时把 encrypted_session_key 发给服务端 # ---------- 服务端 ---------- # 3. 服务端用私钥解出会话密钥 decrypted_session_key = server_private_key.decrypt( encrypted_session_key, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) ) assert decrypted_session_key == session_key # ---------- 后续通信 ---------- # 4. 用会话密钥加密业务数据 nonce = os.urandom(12) ciphertext = AESGCM(session_key).encrypt(nonce, b"业务数据", None) # 把 nonce + ciphertext 发给服务端 # 服务端用同一个session_key解密

这个方案的优点是每个会话使用独立密钥，一次会话泄露不会波及其他会话。同时RSA只加密了一小段会话密钥，性能开销可以忽略。AES-GCM负责大数据量加密，效率和安全性兼顾。

真实生产环境需要考虑的问题当然更多，例如密钥如何安全更新、客户端如何安全获取公钥、防重放攻击等。但在中小型项目中，这套混合加密框架已经足够稳固。

4.4 密钥协商进阶：Diffie-Hellman 密钥交换原理

除了RSA直接加密会话密钥，另一种著名的密钥协商方案是Diffie-Hellman密钥交换（DH），它的特点是双方无需提前共享任何秘密，就能在公开的信道上协商出一个共同密钥，而且监听者无法从公开信息中推导出这个密钥。

用颜色做类比是最容易理解的。假设两个人要协商出一个共享颜色：

1. 双方先约定一个公共颜色（相当于公共参数），比如黄色。
2. 各自选择一个秘密颜色，比如某人选红色，另一人选蓝色。
3. 某人在公共黄色中加入自己的秘密红色，得到一种混合色，发给对方。
4. 同样，另一方在黄色中加入自己的秘密蓝色，把混合色发给某人。
5. 某人在收到的混合色中加入自己的秘密红色；另一方在收到的混合色中加入自己的秘密蓝色。最终两人得到相同的颜色。

监听者能看到公共黄色、第一次混合色和第二次混合色，但无法分离出“秘密颜色”本身，也就无法推导出最终颜色。

真实DH协议基于离散对数难题，原理相同。现代TLS使用的ECDHE就是椭圆曲线版本的DH，同时加入了临时性的密钥参数，实现前向保密。理解了颜色类比，再看TLS密钥交换过程就通透了。

5. 常见问题排查与避坑实录

5.1 对称加密高频问题速查

5.2 非对称加密高频问题速查

5.3 几个我真实踩过并总结的坑

先讲一个IV复用的例子。某团队在业务代码里用固定字符串做AES-CBC的IV，数据加密功能运行正常。后来安全测试发现，同一IV配合同一密钥加密了多份明文，攻击者通过对比不同密文块之间的关系，就能推测出明文之间的相似性，部分敏感信息被还原。这就是典型的模式使用不当。IV不一定需要保密，但必须保证每次加密都唯一。

还有一次RSA签名逻辑错误。某开发者用私钥加密一段摘要，然后拿公钥解密对比，以此实现验签。代码在两端各自验证，看上去没问题。但后来有人指出，这种做法无法保证签名本身是完整的、正规的签名操作，因为RSA解密结果是直接比较，没有经过标准验签算法中规定的签名编码解析流程。正确的做法是使用专门的签名算法，比如RSASSA-PSS或PKCS#1 v1.5签名，签名验签都有专用接口和填充规则，不要把加密和解密接口直接拿来做签名。

再提一个入门者经常遇到的误区：混淆Base64和加密。Base64只是编码方式，不是加密。很多人把字符串转成Base64就以为安全了，其实任何能解码的人都能直接还原成原文。Base64根本不能保护数据，只能用于传输兼容。这个常识说过很多次，但每过一阵就会有人再犯。

5.4 安全性与性能的平衡：怎么选参数

很多初学者会觉得密钥越长越好，算法越复杂越好，这其实未必。密钥长度增加会带来性能下降、资源开销上升，而且不同算法在相同安全强度下的密钥长度差异很大。

一个实用的选型对照：

需要特别提一句密码存储。很多人会问“用户密码该用什么加密”，严格来说密码不能“加密”而要“哈希加盐”。加密是可逆的，如果数据库泄露，攻击者理论上可以解密还原密码。哈希则不可逆，配合随机盐和慢哈希函数，即使数据库泄露，攻击者破解的代价也极高。AES、RSA这些加密方案都不能直接用在这类场景。

6. 最后的经验小结

写到这里，对称加密和非对称加密的核心内容都过了一遍。如果让我用一句话总结这些年的实操体会：加密算法的选型没有银弹，关键是把对称加密的高效、非对称加密的密钥分发能力、以及签名的认证能力组合成一套完整的方案。

我个人在实际项目中的习惯是，先画清楚数据流向，确定需要保护的目标是机密性、完整性还是真实性，再去选算法和参数。反过来直接选一个“听起来最安全”的算法堆上去，往往是在制造新的安全隐患。

再分享一个小技巧：每次设计加密方案时，问自己三个问题——密钥是怎么生成的？密钥存在哪里？密钥丢了或者轮换了怎么办？这三个问题想清楚了，方案至少能挡住八成常见的坑。

最后，加密是一个一旦上线就很难再改的底层能力。方案设计阶段多花些时间，后面省下的工作量是巨大的。在测试环境里把算法逻辑、边界条件、异常处理全部验证清楚，再推上生产。加密无小事，任何一个环节偷懒，都可能在未来某个时间变成安全事故的导火索。