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

本文记录了一次在使用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),出现了无法解密的现象

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值