加密的一些事

互联网的加密层面经常会有一些比较专业的英文，这次来盘点一下:

ssl

安全套接字层。位于传输层和应用层之间的加密层。非对称加密。确保应用层的数据是被加密的

tls

传输层安全。在传输层下的加密层。非对称加密。

ssh

安全shell。使用加密的shell进行远程操作。非对称加密。

gpg

gnu 密钥管理。不仅负责加密，还有签名验证，密钥管理等功能。

rsa

基于质因数分解的非对称加密，非对称加密的鼻祖。什么是对称加密？就是现实中的锁和钥匙，一把锁只能用同一把钥匙解锁。而非对称加密就是一把比较神奇的锁：这把锁有两个钥匙分别为A和B,A钥匙上了锁只能用B钥匙解锁，反之亦然。

假设有A和B要进行安全通信，明文为M，为了保证钥匙分发的安全，使用密钥交换方法:

1. A生成一对密钥KeyAA, KeyAB
2. B生成一对密钥KeyBA, KeyBB
3. 交换密钥,此时A有KeyAA, KeyAB, B有KeyBA, KeyBB。如果存在中间人，将会获得KeyAB和KeyBA。
4. A若发送给B，那么将明文通过密钥加密，设A和B协商，谁发送就用谁生成的钥匙先加密。那么加密的顺序为MS = M -> KeyAA -> KeyBA,其中MS为加密后的密文。
5. 发送给B后,B通过M = MS -> KeyAB -> KeyBB 解密
6. 如果中间人劫持了加密消息MS，并通过社会关系得知了解密顺序, 将通过MS -> KeyAB -> KeyBA 解密。由于非对称性，仍然无法解密。

AES

高级加密标准。是一种传统的对称加密，能够对任意长的数据进行加密和解密。并且基本上无法破解。aes有许多加密模式，分别是ECB，CBC，CFB，OFB和CTR。一般效率比rsa要高，所以通常的做法是：

1. A通过AES加密消息
2. A通过rsa加密AES密钥
3. A和B完成一次rsa密钥交换
4. B收到密钥并对消息解密

MD5

消息摘要。单向加密。将任意的消息映射到一串固定长度的字符串，一般长度为128位，512位等。能够快速验证两个文件是否相同，常常用在文件签名。

SHA

安全hash算法，消息摘要。比MD5更耗时，更安全。

私钥注册

利用非对称加密。比如win10激活，设计软件的会员，其实就是买私钥。买了私钥后就能解密注册程序，进行验证。

https

上面rsa的密钥交换只是适合点对点通信。如果是1 to N通信，比如服务器和用户通信，那么服务器要生成N个公钥，这样非常低效。比如淘宝双11破亿的用户，那么将要同时对破亿的密文进行解密。而且服务器的信息一般是公开的，只有用户的信息是隐私，https,ssl/tls为了避免这样引入了一个新的机制：第三方鉴权CA。服务器生成唯一的私钥和公钥，并将公钥交给值得信任的鉴权机构。用户向鉴权机构获取公钥，并对私钥加密的信息进行解密。如果发送给服务器则通过公钥进行加密。

这时中间人只能知道公钥，能知道服务器发送的消息。由于不知道私钥，就不能篡改服务器的消息，也无法知道用户的隐私。

那么如何防止中间人知道服务器的消息呢？这就是应用层自己的事情了，https只能帮你到这里。

数字签名

在统一的https出现之前，为了防止软件包被篡改而使用的技术。和https的加密和解密手段差不多，只不过中间多了一个过程：不是直接加密整个软件包，而是对软件包生成数字摘要，接着对数字摘要进行非对称加密和第三方鉴权。这样软件的使用者就能知道是否被篡改。比如add-apt-repository就是这个原理。

basexx

一种序列化的方法，通过小字符集表示大字符集。比如只用ascii的a-z表示所有ascii。

base64

对称加密。其实谈不上加密，而是url序列化的方法。http在最开始只有get方法，要将请求包含在url里。url只有一行，可是我们会输入特殊的字符比如空格和换行，因此前端需要替换这些特殊字符得到一行完整的url。后端则对url反序列化即可。

JWT

json token。这个说来话长，先说cookie和session。
众所周知，服务器把用户的id和密码保存到了数据库。以前的逻辑：用户登录->查数据库->信息验证->通过中间件。但是如果一个用户在一个小时内要登录几百次，那么会非常不方便：

• 用户需要反复输入id和密码
• 服务器需要反复遍历数据库

因此两端一拍即合，用户在本地保存一个cookie文件，里面记录了一个cookie id。服务器在数据库维护一个sesson表。每次登录先发送cookie id，服务器通过cookie id查询sesson表，得到id,密码，过期时间等信息。如果没超过过期时间，用户不需要输入id和密码直接登录，超过则重新登录。

随着科技的发展，新的问题又出现了。一个服务器不够用啊，因此采用分布式。但是分布式服务器如何同步sesson表呢?举个例子就是我在服务器A登录，一分钟后由于不限于A故障，A满载，A休眠等原因，我只能通过服务器B登录，那么sesson表同步了吗?

而且如果用户量很大，那么反复查询sesson表也将耗费时间

因此服务器索性将sesson也保存到了用户端

1. 服务器生成密钥
2. 用户A登录服务器，服务器生成session(包含id,密码，过期时间等信息)，加密后发送给A。A在cookie直接保存加密后的session。
3. 用户A再次登录服务器，将cookie中的加密sesson发送给服务器，服务器验证登录是否过期。

加密的session又一个比较高端的名字叫做token。一般不会存放在cookie中，而是存放在请求头的Authentication bearer [token]字段中。