加密 & 解密
备注：密码学领域不存在完全不能破解的密码，但是如果一个密码需要很久很久，例如一万年才能破解，就认为这个密码是安全的了。
对称加密
非对称加密
公钥加密、私钥解密
私钥签名、公钥认证
非对称的底层原理是密码学，密码学的底层是数学。
非对称加密的数学底层原理是：两个大质数相乘很容易得到一个结果，但是相反，将这个结果反推到是哪两个质数相乘却非常困难。
秘钥长度可以理解为两个质数相乘结果的大小，秘钥越长则使用的两个质数的相乘结果越大。
签名 & 验签
私钥签名，公钥认证。
公钥验证数字签名的过程如下：
- 获取要验证的数据、公钥和数字签名。
- 使用公钥对数字签名进行解密，得到解密后的哈希。
- 对要验证的数据进行哈希计算，通常使用与创建数字签名时相同的哈希算法。
- 将哈希计算得到的结果与解密后的哈希进行比较。
- 如果两者完全一致，则表明数字签名有效，验证通过；否则，数字签名无效，验证失败。
再通俗一点：公钥验证通常是 1. 通过使用公钥对数字签名解密后，得到hash值；2. 对data数据进行hash。3. 比较两个hash值是否一样来实现的。
哈希
哈希使用场景1：
对一个很大的文件进行签名很浪费计算机性能，因此一般情况下会先对待签名的文件进行哈希。（通过哈希来提取这个文件的特征-生成固定长度的字符串，也可以理解成这个文件的身份证，即唯一标识）。然后在对哈希值进行签名。
哈希使用场景2：
并不是所有的加密都使用非对称加密，对于很大的文件很浪费计算机性能。通常情况是利用对称加密和非对称加密结合的方式。即通过对称加密算法对大文件进行加密，然后通过非对称加密算法对对称加密的秘钥进行加密。
数字证书
上面的非对称加密已经是非常安全的了，包括验签都是没有问题的。但是还要一个没有解决的问题就是 "中间人" 攻击。
举例：Bob 想要把一个带数字签名的文件传递给 Alice 。于是 Bob 生成了公钥和私钥，用私钥签署了文件。然后把公钥上传到一个公共服务器上。如果一切顺利，那 Alice 去下载这个公钥，然后就可以验证签名，确认文件的确是 Bob 发出的，同时没有被篡改过。但是这里的安全漏洞是明显的，那就是 Alice 无法确认她下载的公钥是不是真的是 Bob 的。这就给所谓的"中间人攻击"提供了可能。假设在 Bob 的文件还没有到达 Alice 之前，黑客发起了中间人攻击，删除 Bob 的文件，然后签署一个假文件发送给 Alice ，Alice 收到后去公共服务上下载的公钥其实也被黑客替换过的，她用这个公钥去验证了签名，自认为文件就是 Bob 发出的，所以被骗了。其实仔细想想，问题就出在公钥本身没有办法证明自己的主人是谁。
所以要避免中间人攻击，就要使用数字证书。Bob 签名文件之后，给 Alice 发送时附上自己的证书。Alice 收到证书之后，就可以信任证书中的公钥的确就是 Bob 的了。有了这个公钥，可以验证文件附带的数字签名是 Bob 的。数字签名没问题，就保证了文件是没有被篡改过的。至于 Alice 如何确认证书本身是可信的，稍后我们聊 HTTPS 的过程中再展开聊。
数字证书是数字签名的升级，数字证书能证明公钥属于谁。
数字证书中的数字签名是CA的签名。
那么怎么确定CA是没问题的呢？计算机或者操作系统等在出厂的时候默认了权威的根证书的公钥，然后就可以来验证传过来的证书的真伪。
数字证书场景的两个应用场景
1、数字签名
如上。
2、HTTPS
比如，我现在用浏览器来访问谷歌服务器。要建立加密通道，首先第一步是要传递公钥过来，但是服务器传递过来的公钥如果过程中被篡改过，那么后续的加密通信也就全无安全性可言了。所以谷歌需要先去 CA 机构申请 SSL 证书，放到自己的服务器上。这样，我在浏览器中输入谷歌的网址，谷歌那边会首先给浏览器发送 SSL 证书。注意，各个浏览器中都内置了对全球各大 CA 机构的验证机制，底层的原理就是拥有 CA 们的公钥，可以验证证书上 CA 的签名。如果证书没有问题，浏览器就可以断定证书中携带过来的公钥就是谷歌的。这时候，浏览器会生成一个秘钥，注意这里就是对称加密的思路了，发送给谷歌服务器。这样，谷歌拥有浏览器的加密秘钥，可以用对称加密的思路来跟浏览器通信了，这样一个双向的加密通信通道也就开通了。对称加密的加密效率要比非对称高，所以大量数据的传递首选对称加密。