消息摘要、各种加密方式的简要说明

本篇不涉及具体的代码实现，相关代码可参考JWT、签名接口的博客
消息摘要

        消息摘要通常采用哈希/散列算法生成，比如MD5、SHA、MAC系列，是一种不可逆的单向算法，它可以把任意长度的信息，生成定长的摘要，并且无法通过摘要信息反向解析出原始数据。所以消息摘要一般用来确保数据传输过程中的完整性。
        发送方在传输时，需要将原始数据与摘要信息同时传递给接收方，接收方再对原始数据进行同样的处理得到新的摘要信息，通过对比两个摘要信息是否一样，即可判断数据在传输过程中是否有被修改。 当然，双方需要提前约定好摘要信息的生成规则。下面这些场景是开发中比较典型的场景：

• 用户登录：对密码生成摘要信息，与存储在DB中的信息对比。
• JWT中，生成header.payload的摘要信息。
• 文件分片上传/文件下载：校验文件的完整性。
• 接口签名：验证接口交互过程中，数据的完整性，防止被修改。

对称加密

        也称单密钥加密，特点是加密/解密使用同一密钥。发送方将数据加密后才传输给接收方，所以发送方需要提前通过其它方式将密钥通知接收方，这里的通知方式不仅仅限于接口传输，也可以是邮件、甚至线下其它方式。由于不传输明文，所以它保证了传输过程中数据内容的保密性，即使数据被截取，在没有密钥的情况下也无法解析出原始数据。这同时也说明密钥的保管非常重要，为了防止密钥泄露，通常会周期性的更新密钥。
        对称加密的相关算法

1. DES(Data Encryption Standard): 数据加密标准，用的比较少，加密强度已经不够，能够暴力破解。
2. 3DES: 和DES差不多，只不过它对数据执行三次加密，增强加密强度。(缺点：要维护3个密钥，增加了维护成本) 
3. AES(Advanced Encryption Standard):高级加密标准，是对称密钥加密中最流行的算法，据说某国安全局就采用了这种方式。

      应用场景，实际开发中对称加密可以与消息摘要一起使用，通过消息摘要确保完整性，对称加密确保密文传输。但是否采用加密，取决于我们对数据安全性的要求高低，毕竟加解密也是一种额外的开销。

• JWT，比如对生成的header.payload的Base64串，你可以进行加密。解析时先解密得到原始数据，再进行摘要的生成与判断。
• 接口签名，同样你也可以对原始数据进行加密，解析也与上一致，只是多一解密过程而已。
• 重要文件传输的加解密。

  非对称加密

        采用公私钥的方式来进行加解密，公钥(PK)加密的数据，只有私钥(SK)能解，反之也一样。它的加、解密算法、公钥都可以公开，但私钥是由公钥决定的，需要严格保密（值得一说的是，虽然私钥由公钥决定，但却不能根据公钥计算出私钥）。与对称加密相比，它不需要外传私钥匙，算法强度复杂，安全性强，但解密耗时也更长。
       相关算法：目前使用最广泛是RSA算法，关于JAVA实现RSA算法，在其它博客中已有相关代码，这里不作说明
       应用场景说明

• 通常与对称加密结合使用。
• 一般当需要加密大量的数据时，由于非对称加密算法的运行速度比对称加密要慢很多，建议采用对称加密算法，但对称加密的密钥管理又非常重要，所以如果有更严格的要求，可以用非对称加密再次对密钥进行加密，这样即实现了密钥的安全管理，同时也保证了加密速度。
• 数字签名：数字签名就是两者结合的一种典型场景。为了确保信息的完整性及来源（确实来源于正确的发送者）。通常会先对信息进行Hash摘要，生成摘要信息，再用私钥进行加密，生成数字签名。将数字签名与摘要信息一同传输给接收方。接收方再用公钥解密得到摘要信息（如果能解开则说明公私钥成对，来源正确），对比摘要信息，即可判断完整性。
• 数字证书：数字证书主要是为了防止中间人攻击。CA认证机构先用自己的私钥对发布者的公钥和相关信息进行加密，生成数字证书。以后发布者在发布信息时，同时带上自己的签名和数字证书，就可以保证信息不被篡改了。接收方先用CA给的公钥解出得到发布者的公钥（能解开则说明来源正确），这样可以保证信息所有者的公钥是真正的公钥，然后就能通过该公钥证明数字签名是否真实了。
• HTTPS：HTTPS传输的安全性就在采用了非对称加密，而且还可以通过CA认证防止中间人攻击，保证证书颁发者的来源。这里有一篇关于相关知识的简易介绍:数字签名是什么
• GitHub：通过SSH方式从Git上进行clone/pull/push等操作时，需要我们在本地先生成公私钥对，然后将公钥上传到Git上，这也是一个典型的场景。（通常项目源码是很重要的）