Diffie-Hellman 加密协议介绍（DH，DHE，ECDHE）

张紫娃

已于 2025-04-10 15:38:46 修改

阅读量1k

点赞数 8

文章标签：网络协议

于 2025-03-18 23:33:24 首次发布

本文链接：https://blog.csdn.net/weixin_37646636/article/details/146347064

版权

什么是 Diffie-Hellman 【/ˈdɪ.fi ˈhɛl.mən/】

由 Whitfield Diffie 和 Martin Hellman 在 1976 年提出的一种非对称加密协议，主要用于密钥交换。

DH 的工作流程

假设小博和小民想要通过不安全的网络协商出一个共享的秘密值，具体步骤如下：
（1）约定公开参数
双方事先约定两个公开参数。
一个大素数 p（作为模数）
一个生成元 g（满足 1 < g < p）。
这些参数可以公开传输，不会影响安全性。

（2）生成私钥和计算公钥
小博：
随机选择一个私钥 a（1 < a < p-1）。
根据公式计算自己的公钥：A = g^a mod p。
小民：
随机选择一个私钥 b（1 < b < p-1）。
根据公式计算自己的公钥：B = g^b mod p。

（3）交换公钥
小博将自己的公钥 A 发送给小民。
小民将自己的公钥 B 发送给小博。
公钥可以在不安全的信道中传输，因为它们本身并不直接暴露秘密值。

（4）计算共享的秘密值
小博：
使用自己的私钥 a 和小民的公钥 B 计算共享的秘密值：Shared Secret = B^a mod p = (g^b mod p)^a mod p = (g^b)^a mod p。
小民：
使用自己的私钥 b 和小博的公钥 A 计算共享的秘密值：Shared Secret = A^b mod p = (g^a mod p)^b mod p = (g^a)^b mod p。
由于模幂运算的性质(g^b)^a mod p = (g^a)^b mod p，所以小博和小民计算出的共享秘密值是相同的：

如果计算的Shared Secret不一致怎么办？
共享的秘密值计算完成后，会进一步使用主密钥派生出会话密钥（Session Keys），并用这些会话密钥加密后续的通信数据。如果密钥不一致，后续加解密会出问题，从而检测到问题。

遇到的问题

虽然 Diffie-Hellman（DH）协议能够安全地协商出共享的秘密值，但它本身并不提供身份验证机制。如果通信双方无法确认对方的身份，就可能遭受中间人攻击（Man-in-the-Middle Attack, MITM）。因为p，g为公开参数，且小博和小民的公钥 A 和 B 是公开的。坏人就可以夹在小博和小民中间，充当中间人，进行冒充了（小博 — 坏人 — 小民）。

如何避免 Diffie-Hellman 中间人攻击？

● 使用数字证书
1、客户端和服务器分别生成自己的非对称密钥对，并向 CA 申请数字证书。
2、客户端和服务器分别交换各自的数字证书 → 验证彼此证书 → 获取对方公钥
3、标准流程：通常只有服务器对 Diffie-Hellman 公钥进行签名，并将 Diffie-Hellman 公钥及其对应的签名一起发送给客户端，客户端验证签名。这种单向验证足以满足大多数场景的需求。（这里用到了数字签名）
特殊情况：在需要相互认证的场景中，双方可以分别对 Diffie-Hellman 公钥进行签名，并互相验证。
4、如果签名验证成功，接收方确认发送方的身份合法。双方继续完成 Diffie-Hellman 密钥交换，协商出共享的秘密值。双方使用协商出的共享秘密值生成会话密钥，用于后续的加密通信。

● 使用数字签名
1、客户端和服务器分别生成自己的非对称密钥对（公钥和私钥）以及 Diffie-Hellman 公钥。
2、发送方使用自己的非对称私钥对 Diffie-Hellman 公钥进行签名。并将 Diffie-Hellman 公钥及其对应的签名一起发送给接收方。
3、接收方收到 Diffie-Hellman 公钥和签名后，使用发送方的非对称公钥去验证签名的有效性。（这里用到了数字证书）
4、如果签名验证成功，接收方确认发送方的身份合法。双方继续完成 Diffie-Hellman 密钥交换，协商出共享的秘密值。双方使用协商出的共享秘密值生成会话密钥，用于后续的加密通信。

哪里避免 Diffie-Hellman 中间人攻击？
CA证书保证客户端获取到的服务器的非对称公钥是百分百正确的，非对称公钥+签名保证Diffie-Hellman 公钥是百分百正确的，客户端的Diffie-Hellman 私钥和服务器的Diffie-Hellman 公钥计算得到的百分百正确的共享的秘密值。服务端Diffie-Hellman 私钥只能和正确的客户端Diffie-Hellman 公钥才能算出与之相等的秘密值，如果不相等就说明存在中间人攻击。

数字证书和数字签名都是你中有我，我中有你，不是单独就可以的

● 预共享密钥（Pre-Shared Key, PSK）
(1) 前置条件
通信双方事先共享了一个预 预共享密钥（Pre-Shared Key, PSK）。

(2) 发送方的操作
1、发送方（如服务器）生成自己的 Diffie-Hellman 公钥。
2、发送方使用预共享密钥（PSK） 对 Diffie-Hellman 公钥生成一个消息认证码（如 MAC）。
3、发送 Diffie-Hellman 公钥和 MAC

(3) 接收方的操作
1、接收方收到发送方的 Diffie-Hellman 公钥和 MAC 。
2、使用相同的 预共享密钥（Pre-Shared Key, PSK） 对接收到的 Diffie-Hellman 公钥 重新生成消息认证码（MAC）。
3、比较接收到的 MAC 和重新生成的 MAC 是否一致。如果一致，则说明 Diffie-Hellman 公钥未被篡改，并且确实由合法的发送方生成。双方协商出共享的秘密值。

哪里避免 Diffie-Hellman 中间人攻击？
如果存在中间人，她无法知道psk，因此无法正确生成mac。当客户端或服务端收到中间人发送的消息时，验证会失败，从而检测到攻击。

传统 Diffie-Hellman (BDH)

1、双方预先生成固定的私钥和公钥，并在多次会话中重复使用。
2、双方交换固定的公钥后，计算共享密钥

静态 Diffie-Hellman (SDH)

和BDH没有本质区别，两者是同一种机制的不同称呼.
BDH更常用于学术或理论描述中。SDH更常用于实际应用或工业标准中。

DHE（Diffie-Hellman Ephemeral）

Diffie-Hellman Ephemeral（简称 DHE）是一种基于 Diffie-Hellman 协议的密钥交换机制，其核心特点是使用临时密钥（Ephemeral Keys），即每次会话生成新的私钥和公钥。

1、双方交换各自的临时公钥。使用自己的私钥和对方的公钥计算共享密钥。
2、会话结束后，临时密钥会被丢弃，不会保存在任何地方。

DHE 的工作流程

（1）初始化连接
双方（如客户端和服务器）通过某种方式（如 TLS 握手）建立连接。双方约定一组公共参数（如大素数 ( p ) 和生成元 ( g )）。
（2）生成临时密钥对
服务器端：生成一个随机的私钥 ( x )，计算对应的公钥 ( X = g^x mod p )。
客户端：生成一个随机的私钥 ( y )，计算对应的公钥 ( Y = g^y mod p )。
（3）交换公钥
服务器将生成的公钥 ( X ) 发送给客户端。
客户端将生成的公钥 ( Y ) 发送给服务器。
（4）计算共享秘密值
服务器端：使用客户端的公钥 ( Y ) 和自己的私钥 ( x )，计算共享秘密值 ( S = Y^x mod p )。
客户端：使用服务器的公钥 ( X ) 和自己的私钥 ( y )，计算共享秘密值 ( S = X^y mod p )。
由于数学性质，( S = (g^y)^x mod p = (g^x)^y mod p )，因此双方计算出的共享秘密值相同。
（5）生成会话密钥
双方使用共享秘密值 ( S ) 生成会话密钥（Session Key）。会话密钥用于后续的加密通信。
（6）销毁临时密钥对
临时密钥对（私钥 ( x ) 和 ( y )）在会话结束后被销毁，无法再次使用。

DHE 的优势

（1）前向安全性（Forward Secrecy）

前向安全性（Forward Secrecy）啥意思？
前向安全性（Forward Secrecy，简称 FS）是一种加密通信的安全属性，确保即使长期密钥（如服务器的私钥）在未来被泄露，也无法解密之前已截获的通信内容。换句话说，前向安全性保护了过去的会话免受未来密钥泄露的影响。

DHE 的局限性

（1）计算开销较大
尽管 DHE 的计算效率较高，但相比其他密钥交换算法（如 RSA），它仍然需要更多的计算资源。特别是在处理大量并发连接时，可能会对服务器的性能产生影响。
（2）依赖公共参数的安全性
DHE 的安全性依赖于公共参数的选择（如大素数 ( p ) 和生成元 ( g )）。如果这些参数选择不当，可能会导致安全性降低。
（3）需要额外的身份验证机制
DHE 本身只负责密钥交换，无法验证通信双方的身份。因此，通常需要结合数字证书或其他身份验证机制来确保通信的安全性。