1. 密码学简介
密码学是通信安全方面的研究，主要分为加密通信与数字签名两个功能：
1.1 信息加密
加密通信分为 对称加密 与 非对称加密。
对称加密拥有同一套密钥，是一种比较简单的加密方式，但是其劣势就是公用的一套密钥可能会被窃取。对称加密最常见的算法是 AES 算法。
而非对称加密是使用了一对公钥和密钥实现了信息的加密，一方用公钥加密信息，而另一方用私钥解密信息。非对称加密的主要算法有两种，一种是 RSA（经典算法）, 另一种是 ECC（比特币加密算法）。
所以对比之下，非对称加密相对于对称加密的的优势在于：信息加密传递的过程中只需要显式传递公钥，私钥由一方保密，外界没有私钥就无法对传递的信息进行解密，所以公钥暴露也无所谓。
1.2 数字签名简介
数字签名（又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。
数字签名是基于非对称加密实现的，是由私钥产生的，公钥可以验证数字签名的有效性：
2. 加密通信
2.1 对称加密
对称加密就是双方使用同一个解密密钥，对信息进行两端的加密和解密。
但是在互联网通信中，服务器端与客户端并不能同时约定一个对信息加密和解密的密钥。只能由一方规定生成密钥后，再将密钥传递给另一方，那么传递的过程中，密钥就有可能被泄露。所以解决如何安全传递对称加密的密钥就成了主要解决的问题。
2.2 非对称加密（公开密钥加密）
非对称加密双发使用了不同的密钥来进行解密，在传递过程中仅传递公钥，所以信息不会对外泄露，这就弥补了对称加密的不足。
其具体的实现流程就是让接收方生成一套公钥和私钥，这两套密钥在数学上关系上有着紧密的联系，但同时不可由私钥推算出公钥。之后接收方将公钥交给信息发送方，信息发送放使用公钥对信息进行加密，发送信息给信息接收方后，信息接收方就可以使用其私钥对加密信息进行解密。
关于私钥与公钥的加密原理，重点在于公钥与私钥之间有 一定的数学联系 ，一般是由一个单向函数实现的，比如 a*b=123312213212 我们并不能逆向推算出 a 和 b 的具体值。
举个简单的例子（引用来源）：
让对方任意想一个3位数，并把这个数和91相乘，然后告诉我积的最后三位数，我就可以猜出对方想的是什么数字！
比如对方想的是123，那么对方就计算出123 * 91等于11193，并把结果的末三位193告诉我。看起来，这么做似乎损失了不少信息，让我没法反推出原来的数。不过，我仍然有办法：只需要把对方告诉我的结果再乘以11，乘积的末三位就是对方刚开始想的数了。可以验证一下，193 * 11 = 2123，末三位正是对方所想的秘密数字！
其实道理很简单，91乘以11等于1001，而任何一个三位数乘以1001后，末三位显然都不变（例如123乘以1001就等于123123）。
所以用上面的例子，我们可以将其整理为一个非对称加密传输信息的模型：
2.3 混合加密
混合加密就是将对称加密与非对称加密相结合而进行信息传递的方式，互联网两端的通信虽然完全可以使用非对称加密来进行，但是非对称加密这种方式及其消耗性能成本，而对称加密更为节省性能。所以我们没有必要全程使用非对称加密来进行通信，只需要使用非对称加密传递对称加密的密钥即可，主要的信息通信仍使用对称加密。
使用混合加密实现的例子有：PGP、HTTPS
3. 数字签名
在上述两节中，公钥的主要作用是用来 加密信息，并没有体现其解密功能，那么为什么要称公钥为钥匙呢？原来除了加密信息外，公钥还可以用来解密数字签名，来验证信息的发送方是否来自于对应的私钥。
所以总结一下，私钥的解密功能主要体现在加密通信（解密key），而公钥的解密功能体现在数字签名（验证key）。
3.1 数字签名的原理
对于加密通信与数字签名的具体过程，私钥与公钥的作用是互相对陈的：
签名算法的输入是文件与私钥，而输出是一串密文；而验证算法的输入时文件、密文与公钥，输出是判定文件的签名是否有效。
对于签名的验证算法是公开的，所有人都可以在自己的计算机上执行验证算法。这段过程中要注意，签名算法并没有对文件进行加密，只是加密了文件的哈希值：
3.2 数字签名的作用
- 认证 —— 确认身份
- 防止抵赖 —— 不能返回
- 防篡改 —— 文件完整
对于防止文件篡改、验证文件完整，这一步是因为验证算法生成的密文是由文件的哈希值与私钥生成的，如果文件在传输过程中遭到篡改或不完整，那么在客户端将传递到文件、密文、公钥进行验证时就会不一致。
4. 数字证书
弄懂了对称加密、非对称加密、数字签名这三个主要概念之后，我们回头看一下，在最合理的混合加密过程中仍存在着不安全的情况。
如果黑客在混合加密传递公钥的这一步拦截了公钥，将其替换为自己的公钥，诱骗客户端生成加密密钥；随后客户端在向服务器传递加密密钥时，黑客再次进行拦截，并将来自客户端的加密密钥进行解密得到密钥，并将解密后的密钥由真正的公钥再次加密发送给服务器端。这样就可以在服务器端与客户端 无法察觉 的情况下获取到两端进行对称加密通信的密钥了。
那么我们来思考一下如何解决安全的传递公钥的这一问题：
我们设想，假如在服务器传递公钥时，同时夹带一张证书，来证明当前的公钥时由服务器发送的，那么如果黑客在中途窃取了拦截了公钥，将“真公钥”替换为了“假公钥”，但是 证书是不能被黑客篡改的 ，那么客户端在验证证书时就会发现公钥不正确，从而防止信息泄露。
我们可以利用我们上一节讲的数字签名来制作这张证书，同时还要有一个可信任的 发证机构（CA） 来颁发这张证书，这也就是 HTTPS 的加密原理。
一张证书通常包含以下几个重要信息：
我们可以注意到证书上有一个数字签名，这个数字签名是由发证机构生成的，用于验证证书的有效性，其对应的验证公钥是发证机构提供的。所以公钥传递的完整流程（也就是HTTPS的加密流程）应该为：
- 服务器在发送公钥前，会拿着该公钥与自己的信息向发证机构提出申请。
- 发证机构收到服务器的申请后，将这些信息进行HASH处理，结合自己的算法生成一个证书的数字签名，并将证书递交给服务器。
- 服务器将证书发送给客户端
- 客户端接收到证书后，拿着发证机构提供的公钥验证证书是否是由发证机构提供的，同时验证其余信息有没有被篡改（这一步提现了非对称加密的验证功能），如果验证通过那么证书中携带的公钥就是可信的。
此时可能会有这两个问题：
问：发证机构的公钥如何获取？
答：发证机构是基于信任的，发证机构的公钥已经对公众公开并集成于浏览器中了。问：证书可能被篡改吗？
答：不可能。如果黑客对数字签名进行了篡改，那么客户端就无法解密；如果黑客篡改了证书中的明文信息，那么客户端在使用 CA 公钥进行签名验证时就会发现解出的HASH与明文信息不对应。