Diffie-Hellman密钥协商算法

概述

DH算法是非对称加密算法的鼻祖，为非对称加密算法奠定了基础，主要用途是进行密钥交换，确保共享的密钥能够安全穿越不安全的网络。该算法其背后有对应数学理论做支撑，简单来讲就是构造一个复杂的计算难题，使得对该问题的求解在现实的时间内无法快速有效的求解（computationally infeasible ）。

这个机制的巧妙在于需要安全通信的双方可以用这个方法确定对称密钥。然后可以用这个对称密钥进行加密和解密。但是注意，这个密钥交换协议/算法只能用于密钥的交换，而不能进行消息的加密和解密。之所以如此，主要还是由于对称加密和非对称加密算法的特性决定的。

1. 对称加密算法和非对称加密算法

对称加密算法

双方使用的同一个密钥，既可以加密又可以解密，这种加密方法称为对称加密，也称为单密钥加密。

优点：速度快，对称性加密通常在消息发送方需要加密大量数据时使用，算法公开、计算量小、加密速度快、加密效率高。

缺点：在数据传送前，发送方和接收方必须商定好秘钥，然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

在对称加密算法中常用的算法有：DES、AES等。

AES：密钥的长度可以为128、192和256位，也就是16个字节、24个字节和32个字节。

DES：密钥的长度64位，8个字节。

非对称加密算法

一对密钥由公钥和私钥组成（可以使用很多对密钥）。私钥解密公钥加密数据，公钥解密私钥加密数据（私钥公钥可以互相加密解密）。私钥只能由一方保管，不能外泄。公钥可以交给任何请求方。

优点：安全。

缺点：速度较慢。

在非对称加密算法中常用的算法有： DH，RSA等。

两者区别

• 算法复杂度:对称密钥<非对称密钥
• 加解密速度:对称密钥>非对称密钥
• 安全性:对称密钥<非对称密钥

对称加密算法相比非对称加密算法来说，加解密的效率要高得多。但是缺陷在于对于秘钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。所以在实际的网络环境中，会将两者混合使用。因此 ，在https中(TLS\SSL)握手阶段使用非对称加密进行对称密钥的协商，而后在后续正常的数据传输时，都会使用对称加密算法进行加密传输。

数学基础

本原根：如果使得 \(a^{m}\equiv 1\ \left( mod\ n \right)\) 成立的最小正幂 \(m\) 满足 $m=\varphi \left( n \right) $ ,则称 \(a\) 是 \(n\) 的本原根。 其中 \(\varphi \left( n \right)\) 为欧拉函数。

性质：若 \(a\) 为模 \(n\) 的本原根，则 \(a\)，\(a\) 的平方，\(a\) 的3次方，……，\(a\) 的 \(\varphi \left( n \right)\) 次m方 模 \(n\) 的余数互不相同，而且构成一个模n的简化剩余系。

栗子(原根)：设 \(n=7\)，则 \(\varphi \left( 7 \right) =7\times \left( 1-\frac{1}{7} \right) =6\)

• 当 \(n=2\) 时，我们需要找到一个 \(m\), 使得 \(2^m\%7=1\)，且刚好 \(m==\varphi \left( 7 \right)\)，首先我们能找到当 \(m=3\) 时，\(2^3\%7=1\)，但是却不等于 \(\varphi \left( 7 \right)\)，因此不满足。
• 当 \(n=3\)时，类比上面一点，可以发现 \(m=6\) 时，两点都能满足。因此 \(3\) 为 \(7\) 的一个原根。

question：找了很多资料对原本根和原根的区别，还是很含糊！有大神的话，希望能教教我，感谢啦！

算法流程及原理

假设Alice需要与Bob协商一个秘钥（秘钥本质上就是一个比特序列，从计算的角度看就是一个大数）。

1. 首先Alice与Bob共享一个素数 \(p\) 以及该素数 \(p\) 的本原根 \(g\) (generator)，且 \(2\le g\le p-1\)。这两个数可以不经过加密的由一方发送到另一方，至于谁发送给谁并不重要，只要保证双方都能知道 \(p\) 和 \(g\) 即可。

2. 而后Alice产生一个私有的随机数 \(A\)，满足 \(1\le A\le p-1\)，然后计算 \(g^Amod\ p=Y_a\)，将结果 \(Y_a\) 通过公网发送给Bob; 与此同时，Bob也产生一个私有的随机数 \(B\)，满足 \(1\le B\le p-1\)，计算 \(g^Bmod\ p=Y_b\)，再将结果 \(Y_b\) 通过公网发送给Alice。

3. 此时Alice知道的信息有\(p\),\(g\),\(A\),\(Y_a\),\(Y_b\)，其中数字 \(A\) 是Alice私有的，只有她自己知道，其他的信息都是别人可能知道的；同样Bob知道的信息有\(p\),\(g\),\(A\),\(Y_a\),\(Y_b\)，其中数字 \(B\) 是Bob私有的，只有自己知道。

   到目前为止，Alice和Bob之间的密钥协商结束。

   Alice通过计算 \(K_a=\left( Y_b \right) ^A\ mod\ p\) 得到密钥 \(K_a\)，同样的，Bob通过计算 \(K_b=\left( Y_a \right) ^B\ mod\ p\) 得到密钥 \(K_b\)，可以证明，必然满足 \(K_a=K_b\)。由此，Alice和Bob得到了相同的密钥，达成了密钥协商的目的。

   证明：\(K_a=K_b\)

   对于Alice有：

   \(K_a=\left( Y_b \right) ^Amod\ p=\left( g^Bmod\ p \right) ^A\ mod\ p=g^{B\times A}\ mod\ p\)

   对于Bob有：

   \(K_b=\left( Y_a \right) ^Bmod\ p=\left( g^Amod\ p \right) ^B\ mod\ p=g^{A\times B}\ mod\ p\)

   上面的运算过程，可根据取模运算的性质可得【a ^ b % p = ((a % p)^b) % p】，由上可得，Alice和Bob生成的密钥其实是进行相同的运算过程，因此必然有 \(K_a=K_b\)。

4. 如果存在一个窃听者Eve，他能否破解密钥呢？很显然Eve能够窃听到 \(p\),\(g\),\(Y_a\),\(Y_b\)，所以问题转变了，Eve能否根据这些信息计算出 \(K_a\) 和 \(K_b\) ？要计算 \(K_a\) 和 \(K_b\) 需要知道A和B。

   以计算A为例，Eve能根据 \(p\),\(g\),\(Y_a\) 通过 \(g^Amod\ p=Y_a\) 计算出 \(A\) 吗？ 目前所知的最佳算法Pollard's rho algorithm for logarithms 时间复杂度是 \(O\left( \sqrt{p} \right)\), 但是实际应用中的 \(p\) 为二进制，假设这个 \(p\) 的长度为 \(n\), 这个复杂度实际上是 $O\left( 2^{\frac{n}{2}} \right) $，这个一个指数级的复杂度，是非常高的。因此求解该问题在计算上的困难程度保证了DH算法的安全性。

安全性问题

那DH密钥协商算法是否就一定安全呢？我们所熟知的，存在一种伪装者攻击(中间人攻击)能够对这种密钥协商算法造成威胁。

假设密钥协商过程中，在Alice和Bob有一个称为Alan的主动攻击者，他能够截获Alice和Bob的消息并伪造假消息，考虑以下情况。

1. Alice和Bob已经共享一个素数 \(p\) 以及其该素数 \(p\) 的本原根 \(g\)，当然Alan也监听到报文得知了这个两个消息。
2. 此时Alice计算 \(g^Amod\ p=Y_a\) ，然而将 \(Y_a\) 发送给Bob的过程中被Alan拦截了，Alan自己选定了一个随机数 \(C\), 计算 \(Y_c=g^C\ mod\ p\), 然后将 \(Y_c\) 发送给Bob。

3. 同时Bob计算 \(g^Bmod\ p=Y_b\)，同样在将 \(Y_b\) 发送给Alice的过程中被Alan拦截下来，Alan自己选定了一个随机数D ，计算 \(g^Dmod\ p=Y_d\) 发送给了Alice

4. 由于Alice和Bob通讯的消息被替换，Alice计算出来的密钥实际上为Alice和Alan之间协商的密钥：\(K_{ad}=g^{D\times A}\ mod\ p\)；Bob计算出来的密钥实际上是Blob和Alan之间协商的密钥：\(K_{bc}=g^{C\times B}\ mod\ p\) 。如果之后Alice和Bob用他们各自计算出来的密钥加密任何信息，Alan截获之后都能够解密得到明文，而Alan也能够伪装成Alice或者Bob给双方发消息，而不至于被发现。

代码为java实现。

参考

https://www.cnblogs.com/qcblog/p/9016704.html

https://www.cnblogs.com/wushaopei/p/11979200.html

https://blog.csdn.net/l18339702017/article/details/81625257

https://www.jiamisoft.com/blog/24603-dcfdcjm.html