前言
本文主要是简单介绍了常见的加密类型、各自的运用场景、为什么需要数字签名和数字证书、HTTPS涉及到的加密流程等。这里主要从使用者的角度出发，对算法本身不做过多介绍。
1. 常见加密类型
- 对称加密：一把密钥，加解密使用同一把密钥
- 非对称加密：两把密钥，公开密钥（公钥）和私有密钥（私钥），其中之一加密，另一个解密
- 不可逆加密(hash)：无密钥，只能从明文转换为密文，无法通过密文获取明文（单向加密）
对称/非对称加密均属于可逆加密，可以通过密钥将密文还原为明文。
有时候，我们希望明文一旦加密后，任何人（包括自己）都无法通过密文逆推回明文，不可逆加密就是为了满足这种需求。
不可逆加密主要通过hash算法实现：即对目标数据生成一段特定长度hash值；无论你的数据是1KB、1MB、1GB，都是生成特定长度的一个Hash值（比如128bit）。这里大家应该能感受到一点不可逆的味道，加密后128bit的hash值显然无法还原出1个G甚至更大的不规则数据的，hash可以看做是原来内容的一个摘要。
三种加密方式的特点都非常明显：
- 【Hash】单向加密/内容摘要；
- 【非对称加密】公钥是可以公开的（不怕泄露）;
- 【对称加密】仅一把密钥，可加解密，双方必须保管好.
选型时，需要根据具体的场景选择最符合的加密类型；值得一提的是，可逆加密中的【对称加密】的整体性能通常会优于【非对称加密】。
常见算法：
- 对称加密：DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6和AES等
- 非对称加密：RSA、ECC、Diffie-Hellman、El Gamal、DSA等
- Hash：MD4、MD5、HAVAL、SHA、SHA-1、SHA-2、HMAC、HMAC-MD5等
- 算法通常是公开的，算法公开时理应是安全的（不然都没人敢用）；后续如果发现漏洞，很快就会有大佬提出解决方案（比如彩虹表攻击和加盐）
- 加解密的单位通常为bit，这也是为什么很多编程语言（如Java）加解密API的输入输出为字节。如果需要用字符串表示，可以使用Base64或Hex编码（Hex从字节到字符串的转换速度快但体积大，Base64相对较慢但体积小）
- 速度慢 不等于 安全性高，新一代的算法往往会比上一代性能更优，且安全性更高。另外不同加密类型的也不能直接简单比较，AES就比RSA性能更好，且安全性完全不输于RSA。但是RSA可以随意派发公钥的特点是AES不具备的。
- 安全性通常和密钥长度、明文复杂性等有关，有密钥的，密钥长度越长越安全，但是相应地计算资源会更多（如AES的密钥长度有分128bit和256bit）；hash这类没密钥的，明文越长、字符类型越多 越安全，像网站密码常要求“字母+数字+不低于X位”。
2 使用场景
2.1 明文通信的隐患
小明给小红写信：
经过九转十八弯后，信的内容有可能：1.被窥视 2.被篡改（冒充小明发送假消息）：
2.2 对称加密
小红先生成对称加密的密钥key1，然后通过一个安全的渠道交予小明。
传输数据时，小明使用key1加密，而小红收到后再使用key1解密。
这时候中间者既看不到原来的内容，也没办法篡改（因为没有密钥）：
【对称加密】实现简单，性能优秀 ，算法本身安全级别高。然而对密钥的管理却是个很头疼的问题：一旦密钥交到对方手里，对方对密钥的保管能力我方是没办法控制的，一旦对方泄露的话，加密就形同虚设了。
相对而言，【非对称加密】的公钥就没有这个忧虑，因为公钥的设计就是为了可以公开的，尽管对方泄露，我方也不会有任何损失。
这里强调我方和他方，主要是和外部系统对接时，总是基于不太信任的角度去考虑安全性的。相对的，如果他方是值得信赖的（内部系统、安全连接等），对称加密就是一个不错的选择。
2.3 非对称加密
小红生成一对公私钥，自己持有私钥（pri_key1），将公钥（pub_key1）交予小明。
传输数据时，小明使用公钥加密，小红使用私钥解密。
因为中间者没有私钥，公钥加密的内容是无法获取的。此时达到了防窥视的效果：
然而因为公钥是可以公开的，如果中间者知晓公钥的话，尽管没有办法看到原来的内容，却可以冒充小明发送假消息：
这时小红在想，如果小明发送消息时，能带上只有他自己才能生成的数据（字符串），我就能验证是不是小明发的真实消息了。
通常这个能证实身份的数据（字符串）被称之为数字签名（Signature）
2.4 数字签名
小明再生成一对公私钥，自己持有私钥（pri_key2），将公钥交予小红（pub_key2）。
当小明传输数据时（可能很大），除了公钥加密明文之外，还要带上签名：(1) 对明文做一个hash摘要 (2)对摘要进行私钥加密，加密结果即签名（传输内容=内容密文+签名）
小红收到后：(1) 解密签名获取hash (2)解密内容密文，对解密后的明文进行hash；如果两个hash一致，说明验签通过。
尽管中间者修改了传输内容，但因为签名无法冒认（没有私钥），小红验签失败，自然不会认可这份数据：
通常非对称加密要做到防窥视和防篡改，需要有两对公私钥：对方的公钥用于内容加密，自己的私钥用于签名（让对方验证身份）。
为什么要做hash摘要？因为签名需要的仅仅是一个不可冒认的数据。我们并不需要对全部明文进行私钥加密，只需对hash摘要即可达到目的。而明文只要有细小变化，hash都会有很大变化。
除了私钥加密，还有其他方式生成签名。比如hash(明文+"双方约定的字符串")，其结果也是无法假冒的，比如很多对接平台中的AppSecret。签名的重点在于“别人无法假冒”。
2.5 HTTPS与数字证书
因为HTTP协议明文通信的安全问题，引入了HTTPS：通过建立一个安全通道（连接），来保证数据传输的安全。
2.5.1 密钥怎么告诉浏览器？
服务器是没办法直接将密钥传输到浏览器的，因为在安全连接建立之前，所有通信内容都是明文的，中间者可窥视到密钥信息。
或许这时你想到了非对称加密，因为公钥是不怕公开的：
然而在第2步，中间者可以截取服务器公钥，并替换成了自己的公钥，此时加密就没意义了：
为了防止公钥被假冒，数字证书（digital certificate ）便诞生了。
2.5.2 数字证书
当服务器需要告诉浏览器公钥时，并不是简单地返回公钥，而是响应包含公钥信息在内的数字证书。
证书需要到权威的证书授权机构（Certificate Authority，CA机构）申请。申请时通常是以公司的名义，需要填写企业编号、证明资料、法人相关信息等，然后审核、颁发。
证书主要包含以下内容：
- 证书拥有者的公钥（这里对应服务器的公钥）
- 颁发机构信息（如由DigiCert Inc颁发的）
- 签名中的hash摘要算法（如SHA）
- 以上等内容的摘要签名（通过【颁发机构的私钥】加密的结果）
浏览器通过【颁发机构的公钥】进行解密验签，验签通过即说明证书的真实性，可以放心取证书拥有者的公钥了。（常用CA机构的公钥都已经植入到浏览器里面）
数字证书只做一件事：保证服务器响应的公钥是真实的。
以上保证了 [浏览器⇒服务器] 是加密的，然而 [服务器⇒浏览器] 却没有（上图第4步）；另外一个是性能问题，如果所有数据都使用非对称加密的话，会消耗较多的服务器资源，通信速度也会受到较大影响。
HTTPS巧妙地结合了非对称加密和对称加密，在保证双方通信安全的前提下，尽量提升性能。
2.5.3 HTTPS建立安全连接的基本流程
HTTPS（SSL/TLS）期望建立安全连接后，通信均使用【对称加密】。
建立安全连接的任务就是让浏览器-服务器协商出本次连接使用的【对称加密的算法和密钥】；协商过程中会使用到【非对称加密】和数字证书。
特别注意的是：协商的密钥必须是不容易猜到（足够随机的）：
其中比较核心的是随机数r3（pre-master secret），因为之前的r1、r2都是明文传输的，只有r3是加密传输的。至于为什么需要三个随机数，可以参考：
SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-master secret就有可能被猜出来，那么仅使用pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了。
以上是一个比较简单的HTTPS流程，详细的可以参考文末的引用。
为什么有HTTPS了，往往还要在应用层进行一次加密/签名？
- 确认发送端的身份。值得注意的是，HTTPS只是保证了传输过程中防止被窥视和被假冒篡改信息，任何人都可以请求建立安全连接（SSL/TCL握手），发送内容。如果想要限制只接受处理某些请求的话，除开IP白名单外，在应用层再加一个签名验证就是个不错的选择。
- 安全性。从客户端到真正处理的应用服务器，途中可能会经过很多中转（代理）服务器，对于极其敏感的数据，应用方并不希望中转服务器有看到明文的机会。另外中转协议并不一定全部都是HTTPS，像内网中转往往就是使用HTTP的（SSL卸载）。
参考资料：
[1] 数字证书应用综合揭秘
[2] SSL/TLS协议运行机制的概述
[3] 图解SSL/TLS协议
[4] 《图解HTTP》
