在工作中使用AES加密過程中遇到的坑，網上資料很少，記錄下來供大家學習參考
業務場景描述：
在一次開發中，我們屬於服務平臺開發很多接口，供其他各個公司的各個系統調用存取數據，但是由於數據安全的問題，領導要求對數據進行加密傳輸，並且不讓自己寫算法實現，經過決定，最終採用AES加密算法進行加密，本人負責此次加密的開發，但是這之中AES加密的坑。不說了，開始介紹：
關於AES和DES，以及3DES這些對稱加密算髮的介紹，這裏不做闡述，只提及一下對稱加密中的祕鑰：
AES ：加密祕鑰指定爲16個字節長度
DES：加密祕鑰指定爲8個字節長度
但是在我們的加密過程中，祕鑰肯定有自己的真正含義，不可能根據算髮的規則去改變我們的業務場景，那麼，就不得不提及一個概念，就是工作模式
它會自動補全祕鑰或者截取祕鑰，按照指定的模式進行算髮截取。
自己開始的加密方式：
1
2
3
4
5
6
7
然而，當把項目部署到服務器上是（linux機器 sun的JDK），出現了無法解密的現象
![如圖所示，（linux）](https://img-blog.csdnimg.cn/20190723152518289.png
原來，祕鑰自動補全如果不指定，就會以系統級別進行祕鑰補全，由於linux和windows的實現機制不同，所以祕鑰補全的算法不同，導致無法解密，解決辦法如下：
這樣以後，一切正常，在windows調用服務，加解密都是正常
這樣，經過各個平臺測試以後，就準備上線，但是，問題纔算來到了，上線以後，有於很多系統使用的是Websphere 的中間件，在測試的時候使用的是tomcat，又出現了無法解密的現象，數據到達服務器後無法解密。
這個問題就頭疼啊，開始把問題一直想着是was中間件的問題，各種查資料，但還是無動於衷，眼看着數據和MQ消息暴增，系統無法取數據。沒辦法，加班，但還是找不到問題呀
接着要過來了調用服務系統的日誌，看了又看，看了又看，最終，問題定位到了
仔細看，was默認使用的是IBM的jdk，而我們系統使用的是sun的jdk，（恍然大悟），前面把加密祕鑰指定到平臺角度，然而現在平臺不一樣了，才造成加解密出現問題（經過反覆測試，確實是這個問題）。知道問題了，那麼接着來解決問題。
解決辦法如下：
由於IBM的jdk和sun的jdk在這個加密類上不一樣，使用的類庫不一樣，那麼，有人會問，到底使用的是IBMJDK下的那個JAR？
%{JAVA_HOME}/jre/lib/ext/ibmjceprovider.jar 使用的是這個包，
還有他的依賴包：%{JAVA_HOME}/jre/lib/ibmpkcs.jar
使用的是這兩個jar，只需要把這兩個jar拿出來，放到項目中引用就可以。
注意：測試了一下，把sunJDK下的加密jar移植到IBM中，會報版本問題的異常。
（本人2019應屆畢業生，如有不合適的地方，歡迎各位大佬指正，感謝！）
————————————————
版權聲明：本文爲CSDN博主「JsonStr_猿」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_20520585/article/details/96996985