前后端通信加密 2: 代码之前需要了解的内容
2018-09-15 本文已影响198人
朴朴乐
先说说AES：
这里有一篇文章比较专业，但对我来说太难了
学霸这边请
虽然看不太明白，但是有几个概念还得稍微了解一下下的：
- 密钥长度
AES的密钥长度，不是随意的。必须是128位，192位，256位中的一种。
128位性能最好，256位更安全；
- 填充
AES是分组加密的，它会把你的明文分成128bit的"块"。问题是，如果待加密的明文长度不是128bit的整数倍的话，剩下最后的一块就需要“填充”，凑够128bit。填充通常有3种模式：
- NoPadding : 顾名思义，不填充。 也就意味着，你需要自己保证你的明文是128bit的整数倍。一般明文都不符合这个要求的， 这个选项基本没有用武之地。
- PKCS5Padding : 这个是默认选项，比较符合人性。在明文块末尾补足相应数量的字符，且每个字节的值等于缺少的字符数。比如明文：{1,2,3,4,5,a,b,c,d,e},缺少6个字节，则补全为{1,2,3,4,5,a,b,c,d,e,6,6,6,6,6,6}
- ISO10126Padding : 如果明文块少于16个字节（128bit），在明文块末尾补足相应数量的字节，最后一个字符值等于缺少的字符数，其他字符填充随机数。比如明文：{1,2,3,4,5,a,b,c,d,e},缺少6个字节，则可能补全为{1,2,3,4,5,a,b,c,d,e,5,c,3,G,$,6}
第二种和第三种，都是可以的，只要跟解密方约定一致即可。
我们就选 PKCS5Padding吧
- 模式
- ECB
ECB模式是最简单直接的，把明文分组，每组分别加密。因为每组的加密都互不影响，所以能够并行计算。但是缺点是安全性略差。 - CBC
CBC在实际中用的多一点。对第一块明文加密后，加密的结果(第一块的密文)又会参与下一个块的的加密（是不是跟区块链有点像？）。可想而知，这种加密模式肯定是个串行的。但是安全性高，只要其中一个块被篡改了，其后所有的块都不正确（确实跟区块链有点像）。
还有CFB和OFB两种模式，没有实际用过，这里就不瞎写了。
我们试试CBC模式吧
- 初始化向量 （IV）
模式中提到的 CBC，CFB，OFB，都需要提供一个值IV。我对这个值的理解是：
如果你用一个明文ABC和密钥xyz总是能生成一个密文 DEF，那么别人看到DEF，就会猜到你的明文是ABC。
这里再加上一个初始化向量，生成的密文会是另外的一个值。这样就大大增加了猜测的难度。
我们提供的这个IV，只会在加密第一个块时用到；其他块会自动生成；
对于我们来说，IV设定一个固定值，加密解密端一致保持就可以了。
以上是关于AES加密的一些介绍。但是事情还没完。
上边提到了 "密钥"。在实际开发中，为了做的更安全一点，我们并不一定会直接给AES一个密钥，我们只会给一个"口令"。
他们有什么区别呢?
口令一般是给"人"用的。基本上跟我们说的“密码”是一个概念。我们通常会选用一个单词或者数字，来帮助我们记忆。比如 “passw0rd”就是一个口令。但是对于计算机来说，如果直接用口令来当成密钥，通常会有安全隐患。太容易被人通过穷举、猜测的方式进行破解；另外，长度也是一个问题，长度不同，安全性是不一样的。因此，我们得的口令一般不会直接做为密钥，而是根据口令通过算法生成一个符合要求的密钥。
这个密钥生成算法，可以看一下 PBKDF2WithHmacSHA1。这个算法大部分的语言都实现了，调用方便，还可以指定生成的密钥长度（这个好，AES的密钥就有长度的要求）。
这里就不重复介绍了，只是简单说一下我们需要用到的变量。
- 盐 （salt）： 一个字符串，需要加密解密两方约定。
- 迭代次数： 整数值， 个人觉的不用太大。 而且前端这个值如果太大的话，感觉对速度影响比较大。我自己的项目里边这个值设定<100
基本就这些了。下一节开始写代码。
