从nodejs的AES加密解密之后文件大小不一致的问题谈谈AES加密中的补位

从nodejs的AES加密解密之后⽂件⼤⼩不⼀致的问题谈谈AES加密中的补位
⼀、AES补位知识
针对 AES 加密的实现过程，⼀般都会⽤到补位。

AES 加密的原数据长度要求是 16 的整数倍，但实际操作过程中并不能保证每次待加密的数据长度都能是 16 的整数倍，所以这时候就需要进⾏补位，再进⾏加密才能得到正确的加密数据。

常⽤的补位⽅式主要：NoPadding，zeroPadding，PKCS5Padding，PKCS7Padding四种⽅式。

其中PKCS5Padding和PKCS7Padding使⽤起来⼀样。

NoPadding：不进⾏补位操作，保持源数据。

zeroPadding：末尾补0操作。

对于源数据长度不是16的整数倍时，在末尾补0⾄长度为16的整数倍；
另外⼀种情况是源数据长度正好是16的整数倍时，需要在数据末尾补16个0。

（需注意）
PKCS5Padding ：对于源数据长度不是 16 的整数倍时，在末尾补(16 - src_len % 16) ⾄长度为16的整数倍；⽐如差3为16的整数倍，那么就部3个3。

另外⼀种情况是源数据长度正好是16的整数倍时，需要在数据末尾补16个16。

（需注意）
PKCS7Padding: 与PKCS5Padding使⽤相同。

⼆、问题描述：
之前做⼤⽂件的分⽚AES加密解密，发现office⽂件，每次打开都会报⽂件损坏的提⽰，然后查看原⽂件和解密后的⽂件发现两个⽂件⼤⼩不⼀致。

⽂件的md5值不⼀样。

所以猜测⽂件是有了变化。

试了很多种⽅式，⽐如IV的偏移向量等，发现还是不⾏，后来看到有个padding（补位）没⽤到，所以猜测通过上⾯的AES补位分析，发现就是因为不满 16 的倍数时，补了相应字节的原因。

三、解决⽅案：
并且后来还发现，⽐如：
1、⽂件为⼀个分⽚，⽂件字节少8成为16的倍数，那么加密之后形成的⽂件就补位了8个8；然后编辑发现⽂件最后多了8个BS字符（ASCII码表看下⽅）
2、⽂件为多个分⽚，⽐如3个分⽚，最后⼀个分⽚少9成为16倍数，那么加密之后⽂件就多了 2*16 + 9 = 41个字节
了解了补位规则所以处理就简单了，在解密之后获取 buffer 最后⼀个字节的值，⽐如16-16-9，那么每次分⽚解密之后，把最后补位的那些16-16-9字节先删掉之后，再合并成新⽂件即可。

亲测完美完成，并且加密解密之后⽂件md5值⼀样，所以有效。