发现想得越多、纠结得越久，越是想把文章写得漂亮点，就越是无法开始。所以，索性随着自己的思绪，想到哪就写到哪吧，再慢慢完善，慢慢补充吧。这篇文章是想做个笔记，跟数据加解密有关的一些东西。
这块知识本来就有点大，先写其中的一块吧，就从对称加密入手吧。
什么是对称秘钥加密？即发送和接收数据的双方使用相同的秘钥对明文数据进行加密和解密运算。 对称秘钥可以分为分组密码和流密码。这里只对工作中常用的分组密码进行介绍。
百度百科：分组密码(block cipher)的数学模型是将明文消息编码表示后的数字（简称明文数字）序列，划分成长度为n的组（可看成长度为n的矢量），每组分别在密钥的控制下变换成等长的输出数字（简称密文数字）序列。
即先对数据进行分块处理，然后再对各个分组块进行加解密处理的的密码算法。
分组密码有如DES、3DES、AES、SM4等的分组对称密钥算法。
分组密码的内容可以简单的分为三块：分组、填充、迭代。
其中，迭代可以选择不同的工作模式，如ECB、CBC、CFB、OFB、CRT，这里说的模式，描述的是如何加密多个数据块。而对单独的一个分组块进行加解密操作的不同，也就是不同分组密码算法之间的区别。
不同的分组密码算法，分组长度也不一样。如AES、DES算法的分组长度是8字节，而SM4算法的分组长度是16字节。
在对明文数据加密前进行分组时，最后一组可能不满足分组长度的要求，因此要进行填充。而在解密后，需要对填充的数据进行剔除。填充方式有多种，常见的填充方式有如：
1、ZeroPadding，数据长度不对齐时使用0填充，否则不填充。 2、PKCS7Padding，假设数据长度需要填充n(n>0)个字节才对齐，那么填充n个字节，每个字节都是n;如果数据本身就已经对齐了，则填充一块长度为块大小的数据，每个字节都是块大小。 3、PKCS5Padding，PKCS7Padding的子集，块大小固定为8字节。
要注意的是：
PKCS7Padding/PKCS5Padding填充时，最后一个字节肯定为填充数据的长度，所以在解密后可以准确删除填充的数据，而使用ZeroPadding填充时，没办法区分真实数据与填充数据，所以只适合以\0结尾的字符串加解密。
此段参考文章：三种填充模式的区别(PKCS7Padding/PKCS5Padding/ZeroPadding)
分组密码中的5种分组模式：ECB、CBC、CFB、OFB、CRT
ECB模式：Electronic Code Book mode（电子密码本模式）（不安全，不推荐）CBC模式：Cipher Block Chaining mode（密码分组链接模式）CFB模式：Cipher FeedBack mode（密文反馈模式）OFB模式：Output FeedBack mode（输出反馈模式）CTR模式：CounTeR mode（计数器模式）5种模式的具体差异可以参考这篇文章：分组加密常见分组模式
主要理解ECB模式和CBC模式，在学习对称秘钥算法时得了解不同工作模式的区别。这样在程序中使用这些对称密钥算法时，才能理解为什么有的示例代码中传的是2个参数：data和key，而有的地方传的是3个参数：data、key、iv。
我们对对称加密算法直观的理解就是加密和解密使用的是同样的密钥key，因此调用加密方法时只需要传key和data即可。可实际上并不是。对于ECB模式的话，只需要一个对称密钥key，而对于CBC模式除了对称密钥key还多一个初始向量iv。而使用CBC模式的加密后的数据较ECB模式而言更加安全。
总之了解不同的分组模式是很有必要的。
它们都属于分组密码，即包含分组、填充、迭代三个部分。它们之前的区别在于分组长度的不同以及迭代中明文分组块与密文分组块的相互转换中使用的策略的不同。
其中，DES是已经过时、不安全能被破解的，而3DES是DES算法的升级版，它相当于对每个分组块应用三次DES加密算法操作，3DES是安全的。AES则更安全且较3DES而言更加高效。而SM4是国密算法的一种，即我国国家密码局认定的国产密码算法。其中sm的含义，一种说法是商(S)用密(M)码。
在工作中经常对接第三方系统，出于数据安全的考虑需要对数据进行加密传输。其中会用到非对称秘钥算法和对称秘钥算法。由于非对称秘钥算法的效率远低于对称秘钥算法，尤其是传输的数据量大的时候。因此非对称秘钥算法不用于直接加密有效数据，而使用对称秘钥来加密有效数据。常用的对称秘钥算法就是AES，但是有的第三方系统要求使用国密算法如ETC蓝牙盒子的密文传输模式，因此偶尔也会用到SM4。
曾在工作中发生过这样的事情，出于安全需要对前端传到服务器的数据进行加密，因此约定使用对称秘钥算法AES来加密数据，于是在网上找了一个AES算法的代码，于是跟前端约定了一个指定的key，可是前端的同事告诉我他找到的AES算法的代码不仅要传key还要传一个叫iv的参数。当时由于没有了解分组密码的分组模式，不知道有ECB和CBC模式，因此一脸懵逼。于是又急急忙忙在网上找了另外的AES算法代码，乱打乱撞，刚好就找到了一个需要传key和iv的示例代码。现在回过头来想想，当时开始找的AES加密代码其实就是使用了ECB模式，因此不需要传iv参数。而前端同事的代码中使用的是CBC模式。再回头看看之前的代码，确实如此。 另外，在我换了一个需要传key和iv两个参数的加解密代码后。能与前端同事在进行数据交互时正常加解密，还有一个碰巧的好运，就是我俩找的AES代码中，使用的填充方式都是同一种。也就是说，如果我们使用的填充方式不同，一端加密，另一端也无法正常解密。
也就是说，对于使用同一种对称秘钥算法的两端而言，如果两端设置的填充方式、分组模式不一致，则双方通信时无法正常进行加解密。而任意一端单独进行加解密操则是正常的。
对于传输数据时使用到的加解密相关的知识（如RSA、SM2、AES、SM4、摘要、MAC、https），会另外写一篇文章做笔记。
