聊聊加解密那些事
什么是加解密
顾名思义我可以通过一个特定的加密方式，让原先的程序员们最爱的明文123456，变成别人看不懂的U2FsdGVxxx，再通过一个特定的解密方式来把数据变回123456。
加密方式
加密又分为对称加密和非对称加密，我们下面详细说一下这两种加密方式。
对称加密
对称加密可以简单理解为，我现在有一把钥匙🔑，我发送信息之前通过这把钥匙进行加密，如果有人给我发送加密信息，我也可以用这把钥匙来进行解密
对称加密主要涉及到以下三种算法
- **AES (Advanced Encryption Standard)**：AES是一种对称加密标准，支持128，192和256位密钥长度。AES加密过程包括多轮的重复和置换。每一轮使用的都是同样的加密密钥，这也就是为什么它被称为对称加密算法。
- **DES (Data Encryption Standard)**：尽管受到批评因为它的56位密钥容易受到穷举攻击，DES在很长一段时间里仍然是行业标准。DES使用的是分组加密方式，数据被分成64位的块，然后按照密钥加密。
- **3DES (Triple DES)**：为了铺平DES的不足，3DES被开发出来，以上述的DES作为基础，重复加密三次以增加其安全性。虽然3DES淘汰了DES的弱点，但是它的处理速度相对较慢。
好处：
我们只需一把钥匙🔑就可以完成加密和解密操作，非常简单
坏处：
但是同时也暴露了一个问题？如何让别人拿到这把钥匙？难道我们通过明文传输这把钥匙🔑吗？显然是不可以的，这时候就引申出了非对称加密
非对称加密
非对称加密就是为了解决别人如何拿到钥匙🔑，在对称加密中我们只有一把钥匙🔑，那么在非对称加密中我们有两把钥匙：一把是公钥，一把是私钥，公钥加密的内容可以用私钥解密，私钥加密的内容可以用公钥来解密
非对称加密主要有以下几种算法：
- **RSA (Rivest-Shamir-Adleman)**：RSA是当前最常见的公钥系统，它基于整数因子分解这种运算困难问题实现。常用于在数据传输过程中加密数据。RSA的安全性基于大数因子分解问题的困难性，JWT属于RS256。
- **DSA (Digital Signature Algorithm)**：DSA 是美国国家安全局推广的一种标准，主要应用于电子签名的情景。DSA在实现上采用了公钥和私钥不同，安全性依赖于离散对数问题，它相比RSA在执行效率上更快。
（OpenSSH 7.0及以上版本默认禁用了ssh-dss(DSA)公钥算法。官方没有给出具体的解释，但其中可能有OpenSSH的DSA密钥位数生成的原因，同时生成签名时随机性差，可能会泄漏私钥，且以现在机算机的算力，DSA 1024-bit已经实际上可破解，建议不使用）
工作方式：
过程：
- 浏览器生成公钥A，私钥A’;服务器生成公钥B，私钥B’
- 通过明文传输浏览器的公钥A给服务器，服务器的公钥B给浏览器
- 浏览器给服务器发消息时用私钥A’进行加密，服务器通过浏览器的公钥A进行解密，成功拿到浏览器加密数据
- 服务器给浏览器发消息时用私钥B’进行加密，浏览器通过服务器的公钥B进行解密，成功拿到服务器加密数据
看上去非对称加密成功解决了我们的问题，但是其实还是有问题存在的，那就是中间人攻击，这个我们等一下再说
抛开攻击先不说，https并没有采用非对称加密来进行数据加密，因为加密是一个非常复杂的过程，那么就意味着解密需要大量的耗时，如果我每一条数据加密解密的时间都很长，用户的等到时间也就增长，那么用户体验就会下降
对称加密+非对称加密
https = http + TLS/SSL(加密) + 身份认证 + 完整性保护
那么最终https的加密采用的是对称加密+非对称加密的形式，那么具体是怎样来实现的
过程：
- 服务器利用非对称加密生成公钥A，私钥A’
- 浏览器请求时，明文传输公钥A
- 浏览器拿到公钥A后，利用对称加密生成秘钥X
- 浏览器用公钥A加密刚刚生成的秘钥X，传回给服务器
- 服务器用私钥A’解密，拿到秘钥X
- 所有数据通过秘钥X进行加密解密
这样就解决了对称加密对方无法拿到秘钥的问题，和非对称加密耗时的问题
中间人攻击
就算使用了对称加密➕非对称加密的形式来加密数据，就一定能保证我们的数据不会被泄露吗？显然世界上没有绝对的事情
中间人攻击其实就是在浏览器和服务器之间有个第三者（小三），我们的数据都经过他，他可以加密和解密我们的数据，那么具体过程如下：
- 浏览器非对称加密生成公钥A，私钥A’
- 想通过明文发送公钥A给服务器，但是此时这个请求被中间人劫持了
- 中间人自己也利用非对此加密生成公钥B，私钥B’,并将公钥B发送给服务器
- 服务器拿到中间人的公钥B后，利用对称加密生成秘钥X，利用公钥B加密后发送回给中间人
- 中间人利用私钥B’解密，成功拿到秘钥X，偷偷保存起来
- 中间人再利用劫持到的公钥A，加密秘钥X，发送给回浏览器
- 浏览器用自己的私钥A’,解密拿到秘钥X，双方开始利用秘钥X进行加密解密数据
- 中间人成功拿到加密数据
在双方都不知道的情况下，数据就这样被泄露了，因为公钥本身是明文传输的，难道还得对公钥的传输进行加密？为了解决这个问题，我们引出身份认证
身份认证
来一个生活场景，我买了一张飞往北京的机票，如果在没有身份认证的情况下，假如有人知道我买了一张机票并且提前前往机场领取机票，那么我就损失了上千元，所以我们就需要验证身份，证明你本人是你本人，那么我们拿机票时就需要身份证才可以成功拿到机票，由权威的政府机关颁发
那么https也是通过专门的权威机构CA（Certificate Authority）来颁发证书来确定你身份的真实性
那么我们就可以这样理解，在https请求中，CA作为一个大家都信赖的大哥，如果某个网站能够拿到这个大哥颁发的证书，那么这个网站的请求都是可靠的
数字证书
在我们使用https请求之前，可以去向CA机构申请证书，证书内容包括域名、申请者信息、公钥信息等等。如果拥有CA机构颁发的证书，那个请求就是可靠的，那么他是通过什么方式来证明这个证书是可靠的呢？
在申请证书时会有相关信息的填写，被认可后，会根据这些信息生成一个签名，比较证书内容和签名是否一致，就可以知道我们的信息是否有被修改
这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名
数字签名
那么数字签名的生成和验证是一个怎么样的过程
生成：
- 受信任的CA机构有非对称加密的公钥A，私钥A’
- 对证书内的相关数据内容进行hash，得到数据X
- 将数据X用私钥A’进行加密，得到数字签名S
证书内容和数字签名一起组成了证书，发送给浏览器，那么浏览器数如何验证的？
验证：
- 浏览器拿到证书后，得到证书内容和数字签名S
- 由于是浏览器信任的机构，所以浏览器保有它的公钥A
- 用公钥A进行解密签名S，得到在生成过程中，hash过后的证书内容数据X
- 用证书里指明的hash算法对证书内容进行hash得到数据X’
- 如果没有被篡改那么 X = X’,等于则表明证书可信
中间人可以对证书内容进行篡改吗？
我们说过中间人攻击，那么中间人可以对证书的内容进行篡改吗？显然是不可以的，假设中间人篡改了证书的原文，但是他没有CA机构的私钥，所以无法修改数字签名。浏览器拿到证书后，会对证书进行验证，解密后就会发现内容不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人
中间人可以直接掉包证书吗？
那么中间人无法修改证书内容，那么中间人直接把整个证书换掉能不能呢？也是不可以的，首先中间人可以通过CA机构获得CA颁发的证书，如果直接把中间人直接把整个证书进行掉包，发送给浏览器。因为证书内部有域名等相关信息，浏览器一对比就会发现，这个证书不是自己的了
一些口嗨加密
在工作的时候我们我们经常会说
- 数据base64加密一下
- 数据md5加密一下
base64
这个是一种编码方式，其目的是将任何数据转换为易移植的字符串，避免了传输过程中失真问题，在处理图片流的时候可以用到
md5
MD5算法是一种哈希算法（散列算法），哈希算法的设计目的本身就决定了，它在大多数情况下都是不可逆的，即你通过哈希算法得到的数据，无法经过任何算法还原回去。 所以既然不能将数据还原，也就不能称之为解密；既然不能解密，那么哈希的过程自然也就不能称作是加密了
总结
在工作中逐渐开始了解并使用到一些加解密手段，加解密涉及到很复杂的密码学，在工作中往往是通过调工具包来解决，所以对整个加解密的背景不是特别清晰，特别是md5加密理论上并不属于加密方式，也是通过后来查阅资料才了解到，所以特此记录一下。
