ECDHE 算法
ECDHE 算法解决了 RSA 算法不具备前向安全的性质 和 DH 算法效率低下的问题。
ECDHE 算法具有前向安全。所以被广泛使用。
由什么演变而来
DH 算法 -- > DHE 算法 -- > ECDHE 算法
DH 算法是非对称加密算法，该算法的核心数学思想是离散对数。
核心数学思想
离散对数
离散对数 是【离散 + 对数】的两个数学概念的组合。
概念如图：
上图中，底数 a 和模数 p 是离散对数的公共参数（公开的），b 是真数，i 是对数。
知道了对数，就可以用上面的公式计算出真数。
反过来，知道真数却很难推算出对数。
特别是当模数 p 是⼀个很⼤的质数，即使知道底数 a 和真数 b ，在现有的计算机的计算⽔平是⼏乎⽆法算出离散 对数的，这就是 DH 算法的数学基础。
DH 算法
前置背景：
小红（客户端） 和 小明（服务端）、DH 算法中的两个公开参数 P 和 G
第一步：
小红生成一个随机数：a（私钥）；小明生成一个随机数：b（私钥）；
第二步：
小红根据 a、P、G 计算出公钥：A（公钥）；小明根据 b、P、G 计算出公钥：B（公钥）；
A = G ^ a ( mod P )； B = G ^ b ( mod P )；
第三步：
小红和小明交换公钥 A 和 B；
第四步：
小红根据 B、a、P 运算得到：K（对称加密密钥）； 小明根据 A、b、P 运算得到 K（对称加密密钥）；
K = B ^ a ( mod P ) = A ^ b ( mod P )
整个密钥协商过程中，小红和小明公开了 4 个信息：P、G、A、B。
根据离散对数的原理，如果 P 是一个大数，在现有的计算机的计算能力是和很难破解出私钥 a、b的。
DHE 算法
来源：
根据私钥的生成方式的分类，DH 算法可以分为两种实现：DHE 算法 和 static 算法（已废弃）
E：ephemeral（临时性的）
作用特性：
让双方的私钥在每次密钥交换通信时，都是随机生成的、临时的。
每个通信过程 的私钥都是没有任何关系的，都是独⽴的，这样就保证了「前向安全」。
ECDHE 算法
来源：
解决 DHE 算法的性能不佳问题。
技术核心：
在 DHE 算法的基础上利用了 ECC 椭圆曲线特性。
具体过程：（在 DH 算法过程的基础上）
- 小红和小明确定好：使用哪种椭圆曲线 和 曲线上的基点 G （都公开）；
- 小红根据 a、G 得到： QA（公钥）；小明根据 b、G 得到： QB（公钥）；
QA = aG；QB = bG；
- 小红和小明交换公钥：QA 和 QB；
- 小红计算点（x1，y1） = aQB ; 小明计算点（x2，y2） = bQA ;
因为椭圆曲线满足乘法交换律和结合律，所以 aQB = abG = baG = bQA。
- 根据此次计算的特性，双方的 x 坐标是一样的，所以 x 为会话密钥。
这个过程中，双⽅的私钥都是随机、临时⽣成的，都是不公开的，即使根据公开的信息（椭圆曲线、公钥、基点 G）也是很难计算出椭圆曲线上的离散对数（私钥） 。
ECDHE 握手过程
与 RSA 算法的区别
- RSA 密钥协商算法「不⽀持」前向保密，ECDHE 密钥协商算法「⽀持」前向保密；
- 使⽤了 RSA 密钥协商算法，TLS 完成四次握⼿后，才能进⾏应⽤数据传输，⽽对于 ECDHE 算法，客户端可 以不⽤等服务端的最后⼀次 TLS 握⼿，就可以提前发出加密的 HTTP 数据，节省了⼀个消息的往返时间（1 RTT）；
- 使⽤ ECDHE， 在 TLS 第 2 次握⼿中，会出现服务器端发出的「Server Key Exchange」消息，⽽ RSA 握⼿ 过程没有该消息；
ECDHE 相比 RSA 握手过程省去了一个消息往返的时间，提高了传输效率。（also mean：抢跑）
TLS 第一次握手：
Client Hello
TLS 第二次握手：
Server Hello
在ECDHE 算法中，这次的密码套件 和 RSA 的不一样。
「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
- 密钥协商算法使⽤ ECDHE；
- 签名算法使⽤ RSA；
- 握⼿后的通信使⽤ AES 对称算法，密钥⻓度 256 位，分组模式是 GCM；
- 摘要算法使⽤ SHA384 ；
Certificate
在ECDHE 算法中， 会在发送完证书后， 发送「Server Key Exchange」消息 。
Server Key Exchange
这个过程服务器做了三件事：
- 选择了名为 named_curve 的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；
- ⽣成随机数作为服务端椭圆曲线的私钥，保留到本地；
- 根据基点 G 和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。
为了保证这个椭圆曲线的公钥不被第三⽅篡改，服务端会⽤ RSA 签名算法给服务端的椭圆曲线公钥做个签名。
Server Hello Done
至此，小红和小明已经共享了 a、b、QB、基点G、使用的椭圆曲线。
TLS 第三次握手
在此之前，先进行证书校验。同时小红计算出公钥 QA。
Client Key Exchange
小红给小明发送了 QA。
至此，双方计算出坐标 x（初级会话密钥）。
但在实际应用中，x 还不是最终的会话密钥。
TLS 握⼿阶段，客户端和服务端都⽣成了⼀个随机数传递给对⽅，最终的会话密钥，就是用【 客户端随机数 + 服务端随机数 + x】三个材料生成。
之所以这么麻烦，是因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性，为了保证真正的完全随机， 把三个不可靠的随机数混合起来，那么「随机」的程度就⾮常高了，⾜够让⿊客计算出最终的会话密钥，安全性更高。
Change Cipher Spec
告诉服务端后续改⽤对称算法加密通信
Encrypted Handshake Message
把之前发送的数据做⼀个摘要，再⽤对称密钥加密 ⼀下，让服务端做个验证，验证下本次⽣成的对称密钥是否可以正常使⽤。
TLS 第四次握手
Change Cipher Spec
Encrypted Handshake Message
握手正式完成，可以正常收发加密的 HTTP 请求和响应了
