AES

AES是一种区块加密标准算法，它的提出是为了升级替换原有的DES加密算法。因此它的安全强度高于DES算法。但不应片面理解，系统和数据的安全不仅与应用的加密算法有关，更与加密应用方案有关。和DES算法一样，AES也属于对称加密算法，对密钥的存储与保护，直接决定了整个系统的安全。

AES最常见的有3种方案，分别是AES-128、AES-192和AES-256，它们的区别在于密钥长度不同，AES-128的密钥长度为16bytes（128bit / 8），后两者分别为24bytes和32bytes。密钥越长，安全强度越高，但伴随运算轮数的增加，带来的运算开销就会更大，所以用户应根据不同应用场合进行合理选择。用户在应用过程中，除了关注密钥长度外，还应注意确认算法模式。AES算法有五种加密模式，即CBC、ECB、CTR、OCF、CFB，后三种模式因其较为复杂且应用较少，不做详细说明，仅对ECB和CBC模式进行介绍。

ECB模式的全称是Electronic Codebook Book，即电码本模式。这种模式是将整个明文分成若干个长度相同的分组，然后对每一小组进行加密，并将加密结果拼接为最终结果，C = C1C2C3......Cn。它与ECB模式的DES算法加密流程基本一致。

CBC模式的全称是Cipher Block Chaining，这种模式是先将明文切分成若干个长度相同的分组（与ECB模式一样），此时先利用初始向量IV与第一组数据进行异或后再进行加密运算生成C1。将C1作为初始向量与第二组数据进行异或后再进行加密运算生成C2。以此类推，当最后一组数据加密完毕后，将加密结果拼接为最终结果，C = C1C2C3......Cn。

综上，AES192算法与DES算法很相似，均为块加密算法，密文数据以16字节为单位独立存在。若明文长度为16字节，当改变明文的前16字节时，只会影响密文的前16字节，密文后16字节不变。因此，在应用AES算法对线路传输数据加密过程中，若想保证密文的整体变化，要保证每块明文数据都是变化的。

---

初始化向量 / IV

在讲加密模式之前首先得要了解一个概念：初始化向量 (IV)

在除ECB以外的所有加密方式中，都需要用到IV对加密结果进行随机化。在使用同一种加密同一个密钥时不应该使用相同的IV，否则会失去一定甚至全部的安全性。

1. 电子密码本 / ECB

 

 

这里$CIPH$指AES加密算法，$CIPH^{-1}$指AES解密算法。

这个很好理解：AES-128 ECB 将明文简单的按照128bit为一个分块进行切割，把每个分块分别进行AES加密，然后再将得到的密文简单的拼接一下即可。

注意到AES加密只能加密128bit的分块，那问题就产生了：如果明文的长度不是128bit的倍数，就会存在一个分块不足128bit，那如何对这个分块进行加密？

别慌，你想到的问题别人早就想到了。为了解决这个问题，我们发明了一种叫做填充的东西，这将会在后面具体讲解。OFB和CTR不需要填充！

ECB模式有一个显著的安全问题：如果使用相同的密钥，那么相同的明文块就会生成相同的密文块，不能很好的隐藏数据模式。这听起来没什么大事，但事实上这对数据安全是一个很大的威胁，下面这张图很明显的体现出了这个问题：

因此，在密码协议中不建议使用ECB模式。

2. 密码块链接 / CBC

在CBC中，每个明文块要先与前一个密文块进行异或后再加密，每个密文块都依赖于前面的所有明文块。

那么问题又来了：第一个明文块怎么办？

这个时候就要用到IV了。在CBC中，IV先与第一个明文块进行异或，得到第一个明文块，然后再进行后续的加密。详见下图：

 

 

这个方法看起来很不错，但有一个缺点：加密过程是串行的，不能并行化，速度比较慢，但是解密可以并行。另外，如果密文的某一位被修改了，只会使这个密文块所对应的明文块完全改变并且改变下一个明文块的对应位，安全性仍然有一定的欠缺。

填充

填充有六种：NoPadding,  PKCS#5,  PKCS#7,  ISO 10126,  ANSI X9.23 和 ZerosPadding

NoPadding

顾名思义，就是不填充。缺点就是只能加密长为 128bits 倍数的信息，一般不会使用

PKCS#7 & PKCS#5

缺几个字节就填几个缺的字节数。

例子：

... | DD DD DD DD DD DD DD DD | DD DD DD DD 04 04 04 04 |

注意：如果当前数据已经是128bits的倍数了也得要填充，否则无法解密。

对于AES来说PKCS5Padding和PKCS7Padding是完全一样的，不同在于PKCS5限定了块大小为8bytes而PKCS7没有限定。因此对于AES来说两者完全相同，但是对于Rijndael就不一样了。AES是Rijndael在块大小为8bytes时的特例，对于使用其他信息块大小的Rijndael算法只能使用PKCS7

2020.5.24更新： 在AES加密当中严格来说是不能使用pkcs5的，因为AES的块大小是16bytes而pkcs5只能用于8bytes，通常我们在AES加密中所说的pkcs5指的就是pkcs7！

ZerosPadding

全部填充0x00，无论缺多少全部填充0x00，已经是128bits倍数仍要填充

例子：

... | DD DD DD DD DD DD DD DD | DD DD DD DD 00 00 00 00 |

ISO 10126

最后一个字节是填充的字节数（包括最后一字节），其他全部填随机数

例子：

... | DD DD DD DD DD DD DD DD | DD DD DD DD 81 A6 23 04 |

ANSI X9.23

跟ISO 10126很像，只不过ANSI X9.23其他字节填的都是0而不是随机数

例子：

... | DD DD DD DD DD DD DD DD | DD DD DD DD 00 00 00 04 |

---

参考资料：
NIST Special Publication 800-38A, 2001 Edition
 

---

加盐 (Salt) 

盐 (Salt) 在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为 "加盐"。密码不能以明文形式保存到数据库中，否则数据泄露密码就会被知道。而一般的加密方式由于加密规则固定，很容易被破解，安全系数不高。密码加盐的加密方式，能很好的解决这一点。

密码加盐里包含随机值和加密方式。随机值是随机产生的，并且以随机的方式混在原始密码里面，然后按照加密方式生成一串字符串保存在服务器。换言之，这个是单向的，电脑也不知道客户的原始密码，即使知道加密方式，反向推出的加密前的字符串也是真正密码与随机值混合后的结果，从而无法解析用户的真正密码。那么是如何验证密码的呢？当你再次输入密码，会以相同的加盐方式生成字符串，如果和之前的一致，则通过。而其它用户无法获得这种加密方式：即生成哪些随机数，以什么方式混入进去，自然就很安全。

 在应用中，出于到安全的考虑和数据的保密，需要使用到加密算法，有时候为了让加密的的结果更加扑朔迷离神鬼莫测一些，常常会给被加密的数据加点“盐”。说白了，盐就是一串数字，完全是自己定义的。

---

HMAC

通过哈希算法，我们可以验证一段数据是否有效，方法就是对比该数据的哈希值，例如，判断用户口令是否正确，我们用保存在数据库中的password_md5对比计算md5(password)的结果，如果一致，用户输入的口令就是正确的。

为了防止黑客通过彩虹表根据哈希值反推原始口令，在计算哈希的时候，不能仅针对原始输入计算，需要增加一个salt来使得相同的输入也能得到不同的哈希，这样，大大增加了黑客破解的难度。

如果salt是我们自己随机生成的，通常我们计算MD5时采用md5(message + salt)。但实际上，把salt看做一个“口令”，加salt的哈希就是：计算一段message的哈希时，根据不同口令计算出不同的哈希。要验证哈希值，必须同时提供正确的口令。

这实际上就是Hmac算法：Keyed-Hashing for Message Authentication。它通过一个标准算法，在计算哈希的过程中，把key混入计算过程中。

和我们自定义的加salt算法不同，Hmac算法针对所有哈希算法都通用，无论是MD5还是SHA-1。采用Hmac替代我们自己的salt算法，可以使程序算法更标准化，也更安全。

Python自带的hmac模块实现了标准的Hmac算法。

HMAC算法是一种基于密钥的报文完整性的验证方法 ，其安全性是建立在Hash加密算法基础上的。它要求通信双方共享密钥、约定算法、对报文进行Hash运算，形成固定长度的认证码。通信双方通过认证码的校验来确定报文的合法性。 HMAC算法可以用来作加密、数字签名、报文验证等 。（我感觉实际情况中用HMAC做加密也是为的不可逆加密，不像用DES/AES这种可逆加密；感觉HMAC和随机盐Hash算法非常像）

一句话总结：HMAC是密钥相关的哈希运算消息认证码（Hash-based Message Authentication Code），HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。

HMAC算法的定义

HMAC算法是一种执行“校验和”的算法，它通过对数据进行“校验”来检查数据是否被更改了。在发送数据以前，HMAC算法对数据块和双方约定的公钥进行“散列操作”，以生成称为“摘要”的东西，附加在待发送的数据块中。当数据和摘要到达其目的地时，就使用HMAC算法来生成另一个校验和，如果两个数字相匹配，那么数据未被做任何篡改。否则，就意味着数据在传输或存储过程中被某些居心叵测的人作了手脚。