JCE中支持AES,支持的模式和填充方式

Java Cryptography Extension(JCE)是一组包,它们提供用于加密、密钥生成和协商以及 Message Authentication Code(MAC)算法的框架和实现。它提供对对称、不对称、块和流密码的加密支持,它还支持安全流和密封的对象。它不对外出口,用它开发完成封装后将无法调用。


JCE中AES支持五中模式:CBC,CFB,ECB,OFB,PCBC;支持三种填充:NoPadding,PKCS5Padding,ISO10126Padding。不支持SSL3Padding。不支持“NONE”模式。
 
其中AES/ECB/NoPadding和我现在使用的AESUtil得出的结果相同(在16的整数倍情况下)。
不带模式和填充来获取AES算法的时候,其默认使用ECB/PKCS5Padding。
 
算法/模式/填充         16字节加密后数据长度         不满16字节加密后长度
AES/CBC/NoPadding              16                         不支持
AES/CBC/PKCS5Padding           32                         16
AES/CBC/ISO10126Padding        32                         16
AES/CFB/NoPadding              16                         原始数据长度
AES/CFB/PKCS5Padding           32                         16
AES/CFB/ISO10126Padding        32                         16
AES/ECB/NoPadding              16                         不支持
AES/ECB/PKCS5Padding           32                         16
AES/ECB/ISO10126Padding        32                         16
AES/OFB/NoPadding              16                         原始数据长度
AES/OFB/PKCS5Padding           32                         16
AES/OFB/ISO10126Padding        32                         16
AES/PCBC/NoPadding             16                         不支持
AES/PCBC/PKCS5Padding          32                         16
AES/PCBC/ISO10126Padding       32                         16
 
可以看到,在原始数据长度为16的整数倍时,假如原始数据长度等于16*n,则使用NoPadding时加密后数据长度等于16*n,其它情况下加密数据长度等于16*(n+1)。在不足16的整数倍的情况下,假如原始数据长度等于16*n+m[其中m小于16],除了NoPadding填充之外的任何方式,加密数据长度都等于16*(n+1);NoPadding填充情况下,CBC、ECB和PCBC三种模式是不支持的,CFB、OFB两种模式下则加密数据长度等于原始数据长度。



  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
好的,下面是使用 JCA/JCE 实现 AES-CBC 模式加解密的示例代码,以及对实验结果的分析。 ``` import javax.crypto.*; import javax.crypto.spec.*; import java.nio.charset.StandardCharsets; import java.util.Arrays; public class AESCBCDemo { public static void main(String[] args) throws Exception { // 初始化 Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider()); byte[] keyBytes = "1234567890123456".getBytes(StandardCharsets.UTF_8); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES"); IvParameterSpec ivSpec = new IvParameterSpec("1234567890123456".getBytes(StandardCharsets.UTF_8)); // 加密 Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding", "BC"); cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); byte[] plaintext = "Hello, world!".getBytes(StandardCharsets.UTF_8); byte[] ciphertext = cipher.doFinal(plaintext); System.out.println("Ciphertext: " + Arrays.toString(ciphertext)); // 解密 cipher.init(Cipher.DECRYPT_MODE, keySpec, ivSpec); byte[] decrypted = cipher.doFinal(ciphertext); System.out.println("Decrypted: " + new String(decrypted, StandardCharsets.UTF_8)); } } ``` 这是一个简单的 AES-CBC 加解密示例,其使用了 Bouncy Castle 作为 JCE Provider。代码的密钥和 IV 都是写死的,实际使用应该根据具体需求生成随机的密钥和 IV。 实验结果分析: 1. 加密过程使用了初始化向量 IV,这一步是必须的,因为如果不使用 IV,相同的明文每次加密得到的密文都是相同的,容易被攻击者破解出密钥。 2. 加密使用了 PKCS5Padding,这是一种填充方式,可以将明文进行填充,使其长度达到 AES 块大小(16 字节)。这一步也是必须的,因为 AES-CBC 要求明文的长度必须是 AES 块大小的整数倍。 3. 加解密使用了相同的密钥和 IV,这是必须的,因为解密需要使用与加密相同的密钥和 IV。 4. 加解密使用了相同的 JCE Provider,这是必须的,因为不同的 JCE Provider 可能实现不同的加解密算法,使用不同的 Provider 可能导致解密失败。 总之,通过 JCA/JCE 实现 AES-CBC 加解密是一个较为简单的过程,但也需要注意一些细节问题,如填充方式、密钥和 IV 的生成等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值