一、背景
将网络请求Post参数加密，选型-AES-CBC-PKCS7Padding 256位
二、前提
后端：PHP 采用AES-CBC-PKCS7Padding 256位
准备：key[32]、iv[16]、Base64[encode、decode]
public static final String KEY_ALGORITHM=”AES”;
private static final String ALGORITHM = “AES/CBC/PKCS7Padding”;这里写成 PKCS5Padding也是没有问题的，为了与ios一致；
至于为什么key是32位? iv是16位？且为什么要使用iv，这里就不多说了。
规则：key不足32位后面都补“0”，iv取key前16位，至于为什么，这些都是和后端协商好的。
上代码：取key和iv
private static byte[] getParamsValue(int lenght) throws UnsupportedEncodingException { byte[] bData = Base64Decoder.decodeToBytes(KEY); byte[] newData = new byte[lenght]; if(bData.length < lenght) { System.arraycopy(bData, 0, newData, 0, bData.length); for (int i = bData.length; i < newData.length; i ++) { newData[i] = ‘0’; } } else { System.arraycopy(bData, 0, newData, 0, newData.length); } return newData; }
private static byte[] getIv() throws UnsupportedEncodingException { return getParamsValue(16); }
private static byte[] getSecKey() throws UnsupportedEncodingException { return getParamsValue(32); }
三、加密
public static byte[] AES_cbc_encrypt(byte[] srcData, byte[] key, byte[] iv) throws NoSuchAlgorithmException, NoSuchProviderException, NoSuchPaddingException, InvalidKeyException, InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException, UnsupportedEncodingException { SecretKeySpec keySpec = new SecretKeySpec(key, KEY_ALGORITHM); Cipher cipher = Cipher.getInstance(ALGORITHM); cipher.init(Cipher.ENCRYPT_MODE, keySpec, new IvParameterSpec(iv)); return cipher.doFinal(srcData); }
byte[] srcData = Base64.decode(data, Base64.DEFAULT) ；
是不是很简单~，网上一搜一大堆。
但是你加密完的字符串，后端真的能解开吗？
反正我遇到的是不行的，那么遇到问题该怎么解决？这里就需要一位很有耐心的phper，多番配合下，终于找到问题。
这里就要理解PKCS7Padding在后端是怎么做的的了？
大家只要看pkcs5_pad就好了，因为unpad用不到
看到后端是如何实现这个pad的补位操作，blocksize就是cipher.getBlockSize()，在AES/CBC/PKCS7Padding下得到的blocksize就是32位。
①补位长度(asc) = blocksize – 将要加密数据的长度(data.lenght)%blocksize
②循环将补位长度的补到加密数据的后面，也就是java：
// 补位操作(不做此操作,后端无法解密成功) int asc = 32 – data.length() % 32; char ascc = (char)asc; String fill = String.valueOf(new char[]{ascc}); StringBuilder sb = new StringBuilder(data); for (int i = 0; i < asc; i ++) { sb.append(fill); }
最后真正的加密数据其实是补位后的，加密到此结束了，开开心心的做解密操作吧。
四、解密
private static byte[] AES_cbc_decrypt(byte[] encData, byte[] pwd, byte[] iv) throws NoSuchAlgorithmException, NoSuchProviderException, NoSuchPaddingException, InvalidKeyException, InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException, UnsupportedEncodingException { SecretKey keySpec = new SecretKeySpec(pwd, KEY_ALGORITHM); Cipher cipher = Cipher.getInstance(ALGORITHM_NOPadding); cipher.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(iv)); return cipher.doFinal(encData); }
看了代码你一定会想 Cipher cipher = Cipher.getInstance(ALGORITHM_NOPadding) 为什么解密用的是
private static final String ALGORITHM_NOPadding = “AES/CBC/NoPadding”;
我也不知道是为什么，为了填这个坑，花了好几天的时间。欲哭无泪~
开始使用的是AES/CBC/PKCS7Padding，没毛病吧，加解密一致。
噩梦就从现在开始了，javax.crypto.BadPaddingException: pad block corrupted，是不是很刺眼。
其实看到这个问题，一开始就应该想是不是Padding出了问题，当时脑袋很能生锈了，去找百度了，
然后各种网友的解决方案就出来了。
问题①：javax.crypto.IllegalBlockSizeException: last block incomplete in decryption
这个问题只要Base64.decode(data, Base64.DEFAULT)解下在解密数据就可以了。
问题②：java.security.InvalidKeyException: Illegal key size or default parameters
这个问题暂时没遇到过，很明显是跟key的大小有关，貌似java8以下不支持256位的原因，本人使用java8没遇到此坑，理论知识很是重要的。
问题③：EVP_DecryptFinal_ex:wrong final block length” during decryption
https://blog.csdn.net/anda0109/article/details/51281070，可以借鉴，但是无效。
方案①：local_policy.jar 和 US_export_policy.jar需添加到%JAVE_HOME%\jre\lib\security中（lib中版本适合jdk）
方案②：UnlimitedKeyStrengthJurisdictionPolicy.ensure();
方案③：Security.addProvider(new BouncyCastleProvider());
以上三方案验证无效；
方案④：使用cipher.update(data) 一定程度上可以解决数据量较小的加密串，但是当拿到的数据太大的时候就痿了，后面还有一大串的数据不见了；
最后pad block corrupted问题，肯定是你的padding与后端padding不一致导致。
