关于在使用AES加密过程中遇到的坑，IBM的JDK和sun的jdk之间加密秘钥补全工作模式的区别

最新推荐文章于 2022-01-20 15:51:46 发布

置顶

JsonStr_猿

最新推荐文章于 2022-01-20 15:51:46 发布

阅读量5.1k

点赞数 3

分类专栏： JAVA 文章标签： java AES 加密 IBM

本文链接：https://blog.youkuaiyun.com/qq_20520585/article/details/96996985

版权

本文记录了一次在使用AES加密过程中遇到的问题，由于IBM JDK和sun JDK在秘钥补全上的实现差异，导致在不同平台上加密后的数据无法解密。解决方案是明确指定加密秘钥和引入IBM JDK的相关加密库。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在工作中使用AES加密过程中遇到的坑，网上资料很少，记录下来供大家学习参考

业务场景描述：
在一次开发中，我们属于服务平台开发很多接口，供其他各个公司的各个系统调用存取数据，但是由于数据安全的问题，领导要求对数据进行加密传输，并且不让自己写算法实现，经过决定，最终采用AES加密算法进行加密，本人负责此次加密的开发，但是这之中AES加密的坑。不说了，开始介绍：

关于AES和DES，以及3DES这些对称加密算发的介绍，这里不做阐述，只提及一下对称加密中的秘钥：
AES ：加密秘钥指定为16个字节长度   
DES：加密秘钥指定为8个字节长度
但是在我们的加密过程中，秘钥肯定有自己的真正含义，不可能根据算发的规则去改变我们的业务场景，那么，就不得不提及一个概念，就是工作模式
它会自动补全秘钥或者截取秘钥，按照指定的模式进行算发截取。
自己开始的加密方式：
![按照这种加密模式指定，一开始没有什么问题，本人开发使用的是tomcat8，sun的jdk win7机器，加解密一切正常](https://img-blog.csdnimg.cn/20190723152104355.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIwNTIwNTg1,size_16,color_FFFFFF,t_70)

然而，当把项目部署到服务器上是（linux机器 sun的JDK），出现了无法解密的现象