引文：两种不同的加密场景
1）防篡改：例如HTTP常使用JWT这样一种Token，其原理是服务器端用公开的哈希函数+自定义字符串KEY构成新哈希函数（实际上与md5+salt密码的加密方案大致是等价的）。当用户登录时，服务端会产生一个JSONObject其中记录了登陆成功的用户名，登录状态失效时间等。然后在这个JSONObject后面附加用这个新哈希函数生成的哈希发给用户，用户之后在报头携带这个JWT使得服务器在每次请求应答中可以知道用户是否登录。由于KEY的保密性与哈希的不可逆特性，几乎不可能从JSONObject与哈希反推出哈希函数，所以当恶意用户企图篡改JSONObject时，无法算出新的哈希。这样一来当服务器颁发出Token后再收到Token时，一定知道其是不是自己颁发的。
2）防泄漏：例如SSL协议中使用的对称/非对称加密，这是真正意义的加密解密。不同于哈希函数有值域小于定义域哈希值不可逆的本质。对称加密模型如下：“两人碰头约定一个方法（密钥），然后各自回家，互相用它来加密解密互相发电报”，这样的模型在WEB中有很大的局限性，因为客户端和服务器不可能线下约定一个密钥，只能线上分发密钥，线上分发时难以保障密钥途中不被泄漏或篡改。所以有非对称加密：“用方法A加密的密文用方法B解密，用方法B加密的密文用方法A解密”，当然具体非对称算法可能有更多的性质，比如“用A可以比较容易推算出B”，此时A为私钥，B为公钥。然后我们来一步步还原HTTPS业务流程：
client: 服务器你好！
server: 客户端你好！这是我的公钥！
client: (公钥加密) dataA
…
server: (私钥加密) dataB
这样数据报在路由的过程中似乎不会被其他中间人“看懂”，但是这种场景下如果一开始的公钥被中间人获取了，所有服务端到客户端的单向数据报都可以被中间人解密，于是改进一下混合使用对称/非对称加密，这样还能提高性能：
client: 服务器你好！
server: 客户端你好！这是我的公钥！
client: (公钥加密) 我们下次用对称算法和对称密钥X来加密
server: (X加密) dataA
…
client: (X加密) dataB
这样X密钥只有服务器能解密出来，又安全了一些。但如果服务器首次应答时公钥被劫持替换掉，下次客户端发送的内容就会被中间人解密得到X，中间人可以持续伪造X加密解密的信息与客户端沟通，于是就有了第三方证书的概念，证书=服务器与客户端建立连接使用的公钥+证书颁发相关信息+签名，服务器有第三方证书签名的私钥，浏览器出厂时内置第三方证书签名的公钥。基于证书的公钥认证逻辑如下：“服务器生成与客户端的公钥后，附加证书信息，最后用证书私钥签名发给客户端。浏览器用内置的对应证书的公钥解密签名，对比密文和证书，证明发送证书方是有私钥的，所以信息是可靠的”，完整的HTTPS流程如下：
client: 服务器你好！
server: 客户端你好！这是我的证书！
client: (公钥加密) 我们下次用对称算法和对称密钥X来加密
server: (X加密) dataA
…
client: (X加密) dataB