椭圆曲线加密算法介绍1-- https 对称加密与非对称加密

最近在工作中涉及到椭圆曲线加密问题，就开始详细的了解了下加密的概念，这篇博客的目的就是为了记录我学习的过程以及复习的依据，同时如果能给正在学习这方面的同道中人，提供一点点的启示作用，那就更好了。（本文主要参考了

网络---Https和Http区别和对称加密和非对称加密）其中大部分图片都是从该文中截图后修改

1.密钥与加密算法之间的关系

这个东西是总被一些人解读的有问题，导致让人区分不开密钥和加密算法

现在来简单的说下：

1).密钥是一种参数（它是在明文转换为密文或将密文转化为明文的算法中输入的数据）

2).加密算法是明文转化成密文的变换函数...是算法

3).同样的密钥可以用不同的加密算法，得到的密文就不一样

举个很简单的例子，比如凯撒密码，就是将字母循环后移n位，这个n就是一个密钥，循环后移的方法叫做算法，对明文用不同的密钥加密的结果不一样，虽然他们用的是相同的算法。
比如Run用Key=1（密钥）的凯撒密码，变成Svo，用Key=2（密钥）加密就成了Twp，所以密钥和算法是明显不同的，再比如现在公钥密码体系大多用的RSA算法，但每个人的密钥不一样，密文才不同。另外，一般来说，算法是公开的，而密钥是不公开的。

2.从https谈对称加密与非对称加密

2.1 对称加密：加密和解密是同一个密钥。

当客户端发送Hello字符串的时候，在进行信息传输前，采用加密算法A(代表任意一个加密算法)和秘钥S将hello加密程JDuEW8&*21!@#进行传输，即使中间被×××劫持了，如果没有对应的秘钥S也无法知道传出的信息为何物，在上图中信息的加密和解密都是通过同一个秘钥进行的，对于这种加密我们称之为对称加密，只要A和B之间知道加解密的秘钥，任何第三方都无法获取秘钥S，则在一定条件下，基本上解决了信息通信的安全问题
但在现实的情况下（www），实际的通讯模型远比上图复杂，下图为实际的通信模型

server和所有的client都采用同一个秘钥S进行加解密，但大家思考下，如果这样的话，无异于没有加密，请做下思考

由于server和所有的client都采用同一个秘钥S，则×××们作为一个client也可以获取到秘钥S，此地无银三百两。所以在实际的通讯中，一般不会采用同一个秘钥，而是采用不同的秘钥加解密，如下图
 

通过协商的方式获取不同的秘钥

如上图，A和server通信采用对称加密A算法和密钥A1，B和server通信采用对称秘钥B算法和密钥B1，因此可以很好的解决了不同的客户端采用相同的秘钥进行通讯的问题

那现在又存在问题了，A通过明文传输和server协商采用了加密算法A和密钥A1，但这条信息本身是没有加密的，因此×××们还是可以窃取到秘钥的，整个的通讯仍然存在风险。那该如何处理呢？有人说，把这条信息（协调秘钥的过程）再次加密，那是不是还要协商加密秘钥，如此反复，永无止境。从根本上无法解决信息通讯的安全问题

总结下就是：

1.单纯使用对称加密无法解决密钥传输问题
2.密钥可能被窃取。

2.2 非对称加密：

密钥成对出现，分为公钥和私钥，公钥加密需要私钥解密，私钥加密需要公钥解密。

一般私钥不公开，公钥公开。

如何对协商过程进行加密呢，在密码学跟对称加密一起出现的，应用最广的加密机制“非对称加密”，如下图，特点是私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

基于上述的特点，我们可以得出如下结论：

1).公钥是开放给所有人的，但私钥是需要保密的，存在于服务端

2).服务器端server向client端（A、B.....）的信息传输是不安全的：因为所有人都可以获取公钥

3).但client端（A、B.....）向server端的信息传输却是安全的：因为私钥只有server端存在

2.3 那么单纯的使用非对称加密可以吗？

使用公钥加密，只能使用私钥解密，所以客户端发给服务器的数据是安全的，但服务端使用私钥，加密后的数据并不是安全的，因为公钥是公开的，所有人都可以解密，但有一点可以保证，就是客户端可以相信这个是服务器端的数据。因为公钥可以解密的一定是使用对应的私钥加密的数据。

2.4 使用两组非对称加密可以吗？

不可以，非对称加密耗时比较长，且无法应对中间人攻击。

2.5 最后，决定使用非对称加密和对称加密进行混合使用。

1.服务器端把公钥发给客户端。

2.客户端使用公钥把对称加密的秘钥加密后发给服务器。

3.服务端使用私钥解密，这时服务端和客户端都拥有对称密钥。

4.服务端与和客户端是用对称密钥传输数据。

https大致使用的就是这个过程。

因此，如何协商对称加密密钥的问题，我们解决了，用非对称加密算法进行对称加密密钥的协商过程，如下所示。

细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。

这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？这个就会有中间人的问题。

lient获取公钥最最直接的方法是服务器端server将公钥发送给每一个client用户，但这个时候就出现了公钥被劫持的问题，如上图，client请求公钥，在请求返回的过程中被×××劫持，那么我们将采用劫持后的假秘钥进行通信，则后续的通讯过程都是采用假秘钥进行，数据库的风险仍然存在。在获取公钥的过程中，我们又引出了一个新的话题：如何安全的获取公钥，并确保公钥的获取是安全的， 那就需要用到终极武器了：SSL 证书（需要购买）和CA机构
 

如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性

图中画的比较简单，省去了 CA机构对服务器的证书的签名过程，下面在验证证书的过程，把这个添加上了。

2.6 如何验证证书

以浏览器为例说明如下整个的校验过程：

1).CA机构进行签名：CA机构拥有非对称加密的私钥和公钥，CA机构对服务器的证书内容进行hash,并对hash后的数据使用私钥加密得到数字签名字符串，证书和数字签名字符串一同发给服务端。

2)服务器端把证书和数字签名字符串明文发给客户端。

3).浏览器（客户端）读取证书中的证书所有者、有效期等信息进行一一校验。

4).浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发。 

5).如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

6).如果找到，那么浏览器就会从操作系统中取出  颁发者CA  的公钥，然后对服务器发来的证书里面的签名进行解密。

（这里需要注意一点，有人会说，能否有人从中间劫持了消息，得到公钥，然后将签名进行解密，然后伪造签名呢，这个是不能的，因为签名需要用私钥进行加密，第三方得不到私钥，所以他只能看看，不能动手脚，然后浏览器发送数据的时候用公钥加密，第三方没有私钥，他想看都看不了了）。

7).浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比。

8).对比结果一致，则证明服务器发来的证书合法，没有被冒充。

9).此时浏览器就可以读取证书中的公钥，用于后续加密了(或者操作系统中存的也行，是一样的)。

上面说的是公钥获取的流程，需要用到签名和认证的流程，签名和认证的流程通常如下描述：（我们不考虑里面对称密钥问题）为了更加清晰的解释 签名和认证的过程，举一个下面的例子来描述问题。

假如现在 Alice 向 Bob 传送数字信息，为了保证信息传送的保密性、真实性、完整性和不可否认性，需要对传送的信息进行数字加密和签名，其传送过程为：

1.Alice 准备好要传送的数字信息（明文）；

2.Alice 对数字信息进行哈希运算，得到一个信息摘要；

3.Alice 用自己的私钥对信息摘要进行加密得到 Alice 的数字签名，并将其附在数字信息上；

4.Alice 随机产生一个加密密钥，并用此密码对要发送的信息进行加密，形成密文；

5.Alice 用 Bob 的公钥对刚才随机产生的加密密钥进行加密，将加密后的 DES 密钥连同密文一起传送给Bob；

6.Bob 收到 Alice 传送来的密文和加密过的 DES 密钥，先用自己的私钥对加密的 DES 密钥进行解密，得到 Alice随机产生的加密密钥；

7.Bob 然后用随机密钥对收到的密文进行解密，得到明文的数字信息，然后将随机密钥抛弃；

8.Bob 用 Alice 的公钥对 Alice 的数字签名进行解密，得到信息摘要；

9.Bob 用相同的哈希算法对收到的明文再进行一次哈希运算，得到一个新的信息摘要；

10.Bob 将收到的信息摘要和新产生的信息摘要进行比较，如果一致，说明收到的信息没有被修改过。

具体的解释如下截图所示：

其实总结下，所谓的签名就是用自己的私钥（非对称加密） 对数据进行加密的过程。

所谓的认证过程，就是将后来的明文也搞成摘要，然后比较两个摘要是否相等。

2.7 如果中间人也去CA机构申请证书，是不是也就可以通过root证书的检查？

不可以，证书中记录有域名等信息，如果是CA机构颁发的证书，很容易发现不是自己要访问的地址。

2.8 使用CA机构的证书有没有漏洞？

有的，还是中间人的例子，如果系统中包含中间人的root证书，就一样有中间人问题，这也是charles等抓包工具的原理。

所以我们不要安装不信任的root证书。

2.9 https的单向验证和双向验证

一般情况下，https只是需要单向认证就可以了。

也就是客户端验证服务器的合法性就可以了，一般服务器端是希望客户端进行访问的，比方百度，淘宝的服务器。

双向认证就是客户端要验证服务器端的身份，同时服务器端也要验证客户端的身份。

而且一般客户端的证书，一般都会使用自签名证书，因为所有的SSL的算法都是公开的，所以CA机构能签发的证书，同样也可以自己签发，问题是自己签发的root证书没有办法内置到所有的系统中去，但如果面对的是封闭的系统，或者我们是系统方，就可以使用自签名证书。

3.对称加密和非对称加密的区别是：

1).对称加密速度快，非对称加密速度慢。

2).对称加密要将密钥暴漏，和明文传输没有区别。

3).非对称加密将公钥暴漏，供客户端加密，服务器使用私钥解密。