我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第1篇文章，点击查看活动详情

什么是加密

考虑以下哪些属于加密方法：AES、RSA、MD5、BASE64、SM4

这几种都是日常开发中常用的数据编码技术，但是只有 AES、RSA、SM4 才能算是加密方法。为什么呢？

一个区分的简单方法就是看编码后的数据是否还能还原，能还原的是加密，因为具有不可逆性、单向恒定性（相同的数据多次计算值不变）的算法一般被应用于文件完整性验证、口令加密以及接下来会讲到的数字签名中。

对称加密

我们平时碰到的绝大多数加密就是对称加密，比如：指纹解锁，PIN 码锁，保险箱密码锁，账号密码等都是使用了对称加密。

对称加密：加密和解密用的是同一个密码或者同一套逻辑的加密方式。

这个密码也叫对称秘钥，其实这个对称和不对称指的就是加密和解密用的秘钥是不是同一个。其特点是加密速度快，但是秘钥容易被黑客截获，所以安全性不高。常见的有AES、DES算法。

非对称加密

目前最常见且广泛使用的非对称加密算法是 RSA 算法， 在非对称加密中，密钥通常由提供服务的一方创建。每次创建是一对公钥（public key）和私钥（private key），然后提供者将公钥给用户，自己保留私钥。非对称加密的特点是安全性高，缺点是加密速度慢。

如果只知道其中一个秘钥是无法推导出另外一个秘钥的

用公钥加密的内容需要用私钥才能解密，用私钥加密的内容需要用公钥才能解密，通常我们使用公钥加密，用私钥解密 。

完整例子

举个例子： 现在 Alice 和 Bob 签合同。Alice 首先用 SHA 算法计算合同的【摘要】，然后用自己私钥将摘要加密，得到【数字签名】。Alice 将合同原文、签名，以及公钥三者都交给 Bob。如下图所示：

Bob 如果想证明合同是 Alice 的

用 Alice 的公钥，将签名解密得到摘要 X。
然后，Bob 计算原文的 SHA 摘要 Y。Bob 对比 X 和 Y，如果 X = Y 则说明数据没有被篡改过。

在这样的一个过程当中，Bob 不能篡改 Alice 合同。因为篡改合同不但要改原文还要改数字签名，而签名是摘要被加密得到的，如果要重新计算签名，就必须提供 Alice 的私钥。

摘要

一般而言，我们不会直接对数据本身直接计算数字签名，为什么呢？

因为数字签名属于非对称加密，非对称加密依赖于复杂的数学运算，包括大数乘法、大数模等等，耗时比较久。

所以一般做法是先将原数据进行 Hash 运算，得到的 Hash 值就叫做「摘要」。

摘要是对原文的证明，防止原文被篡改，从原文到摘要是一个不可逆的过程，也就是无法从摘要反推出原文，同时达到保密的作用。

极少概率碰撞：不同的内容极大概率（绝大多数接近 100%）会生成不同的摘要。

数字签名

数字签名是对摘要的加密，通常在数字签名中，我们使用私钥加密（相当于生成签名），公钥解密（相当于验证签名），「签名」的作用本身也不是用来保证数据的机密性，而是用于验证数据来源的，防止数据被篡改的，也就是确认发送者的身份。

举个例子，Alice 和 Bob 签署一份合同，如果 Alice 将合同生成摘要，再用自己的私钥加密摘要，得到一个密文串，那么这个串就是 Alice 对合同的数字签名（DIgital Sign） 。

如果原文没有被修改，那么下面的条件会满足：

签订合同时的原文摘要 = 数字签名 + 公钥解密
签订合同时的原文摘要 == 摘要算法算出的当前原文摘要

步骤：

接受者 Alice 收到后，取下数字签名，同时用 Bob 的公钥解密，得到「摘要1」，证明确实是 Bob 发的。

1. 如果使用 Bob 的公钥验证签名出错，那么签名一定不是 Bob 的私钥生成的
2. 使用数字签名，我们能够鉴别消息的发送者，也就是说 黑客无法伪装发送者进行发送数据（并不一定） ，也无法篡改。

再对邮件内容使用相同的散列函数计算「摘要2」，与上面得到的「摘要1」进行对比，两者一致就说明信息未被篡改。

这样两步分证明发送者身份和保证数据未被篡改。

数字证书

数字证书叫做「公钥的数字签名」， 引用百度百科解释：数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。

冒充风险

但是在上面描述的过程当中，仍然存在着一个非常明显的信任风险。无法消除冒充风险。

考虑如下场景：

攻击者把服务端的公钥拦截，并保存下来。
攻击者伪造成服务端，把自己的公钥发送给客户端。
攻击者拦截使用非法公钥加密后的对称密钥，解密后得到对称密钥明文，并保存下来
攻击者使用服务端公钥重新加密对称密钥，伪造成客户端发送给服务端。

这番操作后，攻击者就能在客户端和服务端都不知情的情况下，得到了对称密钥。在这种场景下，攻击者从被动攻击的窃听，转为主动攻击的冒充，让客户端和服务端都误以为一直在跟对方通信。

CA证书

世界上有一个神秘的组织：CA机构 。就是它会给网站颁发身份证。当某个网站想要启用HTTPS协议的时候，需要向CA机构申请一份证书，这个证书就是数字证书。

数字证书 包括了证书持有者信息、网站公钥和有效期等等等信息。

CA 颁发的数字证书我们通常称作 CA 证书

如上图所示：

Alice 将自己的申请提交给CA机构，产生证书的原文。
CA机构用自己的私钥签名 Alice 的申请原文，得到带有签名信息的证书。
Bob 拿到带签名信息的证书，通过预存的CA机构的公钥进行解密，获得 Alice 证书的摘要。

CA证书-验证签名

如下图，假想服务器为Alice，浏览器为Bob

Bob 进行验签。

用 CA 公布的公钥对证书签名进行解密，得到数字摘要T。再使用同样的算法对证书明文信息计算得出数字摘要S。对比数字摘要T和数字摘要S是否相等。

验签通过，Bob 就可以确认 Alice 的证书的确是CA机构签发的，如果 Bob 也信任这个CA公证机构，信任关系和签约就成立。

CA证书-通信过程

总结上述步骤如下：

双向认证

非对称加密常用应用场景就是双向认证。所谓的双向认证就是不仅服务端要验证客户端的身份，客户端也要验证服务端的身份。说白了就是客户端和服务端各自生成一个密钥对，私钥自己保存，公钥发给对方。这种情况一般用在系统与系统的对接上。

两者对比

非对称加密中公私钥都可以加密，那么什么时候用公钥加密，什么时候用私钥“加密” ？
- 加密场景，那么肯定希望只有我才能解密，别人只能加密。即私钥解密，公钥加密。
- 签名场景，既然是签名，就希望只能我才能签名，别人只能验证。即私钥签名，公钥验签
什么是数字签名，数字签名的作用是什么？
- 数字签名就是使用私钥对数据摘要进行签名，并附带和数据一起发送。
- 可以起到防篡改、防伪装、防否认的作用。
为什么要对数据的摘要进行签名，而不是直接计算原始数据的数字签名？
- 数据可能比较大，签名是使用非对称加密算法，比较耗时
- 防止第三方使用公钥解开签名后，拿到原始数据
什么是数字证书，数字证书存在解决了什么问题？
- 数字证书就是由 CA 机构使用自己私钥，对证书申请者的公钥进行签名认证。
- 数字证书解决了如何安全分发公钥的问题，也奠定了信任链的基础。

HTTPS协议

在HTTPS中传输数据时不会使用非对称加密加密传输数据，传输数据时有可能数据本身很大，那样的话非对称加密更耗时了，所以传输数据时不会使用非对称加密的方式加密。

加密扩展

在HTTPS的加密中，加密传输的数据本身使用的是对称加密，加密对称秘钥时使用的非对称加密。

通常情况，非对称加密需要更多的运算资源。因此很多协议使用非对称加密解决最核心的安全问题，再用对称加密解决其他问题，最典型的案例就是HTTPS协议。

非对称加密+对称加密 = 雏形

假设服务器预存了一套公钥（假设叫 A+ ）和私钥（假设叫 A- )

1、浏览器向服务器发起请求；

2、服务器将自己的公钥A+ 返回给浏览器；

3、浏览器在本地生成一个密钥B，然后利用公钥A+ 对密钥B进行加密，加密之后传输给服务器；

4、服务器收到数据，利用私钥A-对数据进行解密，拿到浏览器生成的密钥B；

5、之后双方的通信，都用密钥B进行。

完整版通信过程

通过证书来保证互相的真实性，具体请看上述【CA证书-通信过程】

为什么可以相信一个 HTTPS 网站？

当用户用浏览器打开一个 HTTPS 网站时，会到目标网站下载目标网站的证书。

接下来，浏览器会去验证证书上的签名，一直验证到根证书，如果根证书被预装，那么就会信任这个网站。

也就是说，网站的信用是由操作系统的提供商、根证书机构、中间证书机构一起在担保。

特别注意的是，如果犯罪分子设法在你的个人电脑上安装了它的根证书，那后果就严重了，它可以冒充成任何网站。

为什么浏览器中我按个F12还是能看到明文？

所谓的HTTPS，其实就是HTTP + SSL/TLS两种协议的合体，同时，HTTP协议是应用层协议，而SSL/TLS是传输层协议。

那问题的答案就很清晰了，在你能够在浏览器上面查看网页之前，报文经过了你的传输层，SSL/TLS已经对报文进行了解密处理（快递已经开包）。之后所以不管是在浏览器上呈现，还是你按F12查看源码，都是HTTP协议的事情（快递里面的东西都已经到你手上了，对你而言不会再有啥秘密）

参考

本文图中部分内容和图总结自

《假如让你来设计SSL/TLS协议》，作者：元闰子
《计算机网络通关 29 讲》，作者：林䭽

结合对称加密、非对称加密浅析HTTPS协议