發現想得越多、糾結得越久，越是想把文章寫得漂亮點，就越是無法開始。所以，索性隨着自己的思緒，想到哪就寫到哪吧，再慢慢完善，慢慢補充吧。這篇文章是想做個筆記，跟數據加解密有關的一些東西。
這塊知識本來就有點大，先寫其中的一塊吧，就從對稱加密入手吧。
對稱密鑰
什麼是對稱祕鑰加密？即發送和接收數據的雙方使用相同的祕鑰對明文數據進行加密和解密運算。
對稱祕鑰可以分爲分組密碼和流密碼。這裏只對工作中常用的分組密碼進行介紹。
分組密碼是什麼？
百度百科：分組密碼(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、AES、SM4之間的異同
它們都屬於分組密碼，即包含分組、填充、迭代三個部分。它們之前的區別在於分組長度的不同以及迭代中明文分組塊與密文分組塊的相互轉換中使用的策略的不同。
其中，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），會另外寫一篇文章做筆記。