什么叫个非对称加密？中间人攻击？数字签名?

非对称加密也称为公钥密码。就是用公钥来进行加密，撒子意思？

非对称加密

在对称加密中，我们只需要一个密钥，通信双方同时持有。而非对称加密需要4个密钥，来完成完整的双方通信。通信双方各自准备一对公钥和私钥。其中公钥是公开的，由信息接受方提供给信息发送方。公钥用来对信息加密。私钥由信息接受方保留，用来解密。

举一个简单的例子说明一下非对称加密：

我们有熊大 熊二两只熊，

熊大有自己的私钥 mmPrivateKey，和公钥mmPublicKey，熊二有自己的私钥 xxPrivateKey，和公钥xxPublicKey

熊大将自己的公钥mmPublicKey发给熊二，熊二将自己的公钥xxPublicKey发给熊大

熊二给熊大说“光头强又来砍树了”，这句话用了熊大的公钥mmPublicKey进行了加密，并且发送给熊大，这样熊大就能用自己的私钥 mmPrivateKey去解密，拿到信息，这一顿操作光头强因为没有熊大的私钥，即使截取了信息也无法打开。

熊大收到信息之后，说“我们去抓他”用熊二的公钥去加密，发给熊二，熊二收到之后用自己的私钥xxPrivateKey去解密拿到信息。

以上过程是一次完整的request和response。通过这个例子我们梳理出一次信息传输的非对称加、解密过程：

1、消息接收方准备好公钥和私钥

2、私钥 接收方自己留存、公钥发布给消息的发送方

3、消息的发送方使用接收方公钥对消息进行加密

4、消息的接收方用自己的私钥对消息解密

公钥只能用做数据加密。公钥加密的数据，只能用对应的私钥才能解密。这是非对称加密的核心概念。

中间人攻击

中间人攻击指的是在通信双方的通道上，混入攻击者。他对接收方伪装成发送者，对发送方伪装成接收者。

他监听到双方发送公钥时，偷偷将消息篡改，发送自己的公钥给双方。然后自己则保存下来双方的公钥。

如此操作后，双方加密使用的都是攻击者的公钥，那么后面所有的通信，攻击者都可以在拦截后进行解密，并且篡改信息内容再用接收方公钥加密。而接收方拿到的将会是篡改后的信息。实际上，发送和接收方都是在和中间人通信。

拿上面的例子来说，如果光头强想要知道熊大熊二之间的通信消息，那么在熊大将自己的公钥以明文方式发给熊二的时候，光头强劫持到这个mmPublicKey，然后把自己的公钥B发送给熊二（熊二不知道被劫持了，以为B就是熊大的公钥），然后熊二把自己的公钥xxPublicKey发给熊大，说咱们来进行后面的通信，可惜这个公钥也被光头强劫持了，（光头强把自己的公钥B又发给熊大），熊大收到后同样以为B也是熊二的公钥，至此熊大熊二之间的信息通信都用光头强的公钥B进行加密，光头强就可以用自己的私钥进行解密拿到信息。

当然中间人一般并不是就把信息拿到之后就不给了，而是处于一个监听偷听偷换的状态，所以举一个更恰当的例子说明一下:

1、某网站服务器拥有用于非对称加密的公钥A、私钥A’。
2、浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3、中间人劫持到公钥A，并保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。然后发给浏览器。
4、浏览器拿到之后，随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。
5、中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
6、服务器拿到后用私钥A’解密得到密钥X。

这样中间人就获取了两个用来加密通信的对称秘钥X，且双方也不知道。

那么如何证明浏览器收到的公钥一定是该网站的公钥？ 防范中间人需要用到数字签名

数字签名

网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。然而这里又有一个显而易见的问题了，证书本身的传输过程中，如何防止被篡改？即如何证明证书本身的真实性？

我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名

明文信息 ——》 进行hash（SHA1/md5） ——》 得到摘要（Digest） ——》 使用A私钥对摘要（Digest） 加密 ——》 明文 和 数字签名 组成 签名结果---》发送过去

对方收到之后

用A公钥对摘要进行解密---》》拿到摘要---》再对发来的明文进行hash得到摘要--》两份摘要进行比对--》就能发现发来的文件有没有被篡改
 

这一切的前提是对方能有A公钥，但如果通过一些手段对方拿到的不是A公钥，且对方还不知道，比如拿到了B公钥，那么骗子就能用自己的B私钥进行一系列签名活动，对方拿B公钥解密之后就拿到了假信息
 

非对称加密技术的加解密和签名的过程中发送方用哪个密钥进行加
密和签名，接收方用哪个密钥进行解密和验证签名？
加密使用接收方的公钥，签名使用发送方的私钥；接收方解密用接
收方的私钥，验证签名使用发送方的公钥。使用接收方的公钥加密
只有接收方可以解密，使用发送方的私钥签名，该签名只能由发送方施加；

那么怎么确定自己手头的公钥是真的呢？这就需要第三方的帮忙确认了

数字证书

网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。

我们申请证书，证书里存的就是对方所需要的发送者的公钥，以及发送者的信息，既然花钱申请了证书，那么机构就会用自己的私钥把证书加密，然后把对应的机构公钥给你，你拿到之后，用机构的公钥打开证书，拿到里面的发送者信息，以及发送者的公钥，这样确保拿到的公钥的的确确是正确的了。

说白了正常我们验证数据对不对，用了数字签名，但前提保证我们手里的钥匙得是对的，所以为了保证钥匙是对的，我们在发数据之前先对钥匙进行一次权威的数字签名，也就是所谓的申请数字证书，确保拿到钥匙是对的。其实就是个签名套签名

数字证书验证过程（和数字签名验证一样，只不过是签名套签名）
拿到证书，得到明文T，数字签名S。
用CA机构的公钥对S解密，得到S’。（由于是浏览器信任的机构，浏览器保有它的公钥，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥）
用证书里说明的hash算法对明文T进行hash得到T’。
比较S’是否等于T’，等于则表明证书可信。