AES 解密 Android 与 iOS 行为不同

[Gehrman]

AES/CBC/PKCS5PADDING 128 位

key:42fa7a440ae94c0e 偏移量：1236455559543215

a.原文 15068#1574908387

b.加密后转 Base64 字符串：K/pPwvZh689ZW/ud2ykbKYcWNWCyI1ScsFzvlZb8qs8=

c.设备端将 a 加密后转 Base64 字符串：K/pPwvZh689ZW/ud2ykbKQ==

现在情况是 iOS 端能将 c 解回原文，但 Android 不行，会报错。Android 在 a 和 b 之间互相转换是 OK 的，而且 iOS 按规则加密生成的其实也是 b。

K/pPwvZh689ZW/ud2ykbKQ==
K/pPwvZh689ZW/ud2ykbKYcWNWCyI1ScsFzvlZb8qs8=
这两段密文 iOS 用同样的 key 和 iv 都解成了 15068#1574908387
而 Android 和在线工具及前面朋友的验证都只能解第二段密文

[ysc3839]

用什么库解密的？报什么错？代码？

[xiangyuecn]

.net 的，你那 ios 瞎几把写吧

[littleylv]

做过 iOS、Android、PHP 三端的相互加解密（ AES/CBC/PKCS7Padding ），没有问题。

楼主贴代码吧（ v2 回帖代码不好看，建议 gist ）

[xiangyuecn]

ios 的那坨这么短，目测应该是没有填充😂

[Gehrman]

Android 用的自带的库，报错是这个 BadPaddingException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
现在关键的是 Android 的加密和解密和在线工具是一样的

[Gehrman]

@littleylv
private fun decrypt(message: String, keyStr: String): String {
//Base64 字符串转为加密后的数据
val plaintext: ByteArray = Base64.decode(message.toByteArray(), Base64.NO_WRAP)
//根据 keyStr 生成 secret key
val secretKey = SecretKeySpec(keyStr.toByteArray(Charsets.UTF_8), "AES")
//根据 ivParameterSpecStr 生成 IvParameterSpec
val ivParameterSpec = IvParameterSpec(ivStr.toByteArray(Charsets.UTF_8))
val cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING")
cipher.init(Cipher.DECRYPT_MODE, secretKey, ivParameterSpec)
//解密
val decryptResult = cipher.doFinal(plaintext)
//将解密结果转为字符串
return decryptResult.toString(Charsets.UTF_8)
}

现在主要是 iOS 那边怎么能做到解密，虽然这种情况很少，但是遇到了也是好奇

[ZavierXu]

不要怀疑算法……肯定是你自己写错了……

[Gehrman]

@xiangyuecn 瞎写正常应该也解不出来吧，这种情况遇到两次了，第一次以为 Android 这边写错了，好奇 iOS 有什么奇怪的方法

[mcluyu]

iOS CommonCrypto 库里就只有 kCCOptionPKCS7Padding 和 kCCOptionECBMode，没有 PKCS5PADDING，如果 Android 和其他端能对应， 那应该是填充问题。

[Gehrman]

@mcluyu 跟 iOS 那边对了下，设置确实是 PKCS7Padding，但是这也解释不了 iOS 为什么能将 c 和 b 都解回 a。而且在线工具设置成 PKCS7Padding 结果跟主题也是一样的

[codeisjobs]

我正好做了这个。

[codeisjobs]

和你情况差不多，安卓单独加解密没问题，iOS 单独加解密也没问题，服务器单独也没问题，服务器到安卓也没问题。iOS 的到服务器就有问题，后来查出来是 iOS base 64 加密格式和通用的不太一样。需要换个参数，这个就得自己试试是哪个参数正确的了

[littleylv]

@Gehrman #6 Swift 的话我用的这个库： https://github.com/krzyzanowskim/CryptoSwift

[jenschen]

做过 aes 和 rsa，三端都没有问题。一般现成的库应该不会有问题。仔细看看加密模式，长度是否相同。

[Gehrman]

@codeisjobs 我是开发 Android 的，现在 95%的情况我们三端是 OK 的，剩下的就是主题中提到的 iOS 能解 b 这种”不规范“的密文，
只是不想到时候被测试 bb 为什么 iOS 可以 Android 不行才发的这个贴。
设备端老哥已经在看问题，不知道能不能避免生成 c 这种密文

[Gehrman]

@Gehrman 楼上应该是---iOS 能解 b 这种”不规范“的密文，

[Gehrman]

@littleylv iOS 目前貌似还不需要修改，而且他们用的是 OC。。。

[codeisjobs]

@Gehrman 大概率是 iOS 的 bade64 加密参数用的默认的，导致生成后不规范。

[codeisjobs]

@Gehrman 可能 iOS 还要做加密后，把密文里的\r\n 给去掉。。。坑爹 iOS 会做换行

[Gehrman]

@codeisjobs 目前情况下 iOS 应该不需要修改，现在是 iOS 能解的 Android 不能解，Android 不能解的别的端也不能解，所以现在应该是设备端的锅吧 orz

[longaiwp]

@Gehrman base64 要注意自动填充\n 的坑爹问题,这可能是一个因素

[Gehrman]

@longaiwp 这个设置了 Base64.NO_WRAP，应该不会了

[codeisjobs]

@Gehrman iOS 能解，安卓不能解？密文不是服务器下发的吗？

[42byte]

@littleylv CryptoSwift 是作者自己用 Swift 重新实现了 AES 算法，走 CPU 计算的，没使用系统自带的 CommonCryptor 不能硬件加速，性能很差

[littleylv]

@42byte #24 谢谢科普

[elvodn]

这里 55 - 57 行 自动处理了未 PADDING 格式
https://github.com/krzyzanowskim/CryptoSwift/blob/master/Sources/CryptoSwift/PKCS/PKCS7Padding.swift#L55

[Gehrman]

@codeisjobs 是服务器下发的，
K/pPwvZh689ZW/ud2ykbKQ==
K/pPwvZh689ZW/ud2ykbKYcWNWCyI1ScsFzvlZb8qs8=
这两段密文 iOS 用同样的 key 和 iv 都解成了 15068#1574908387
这就是我疑惑的点

[codeisjobs]

@Gehrman 如果是服务器下发的密文，安卓解不了，那可能是安卓的代码有问题。一般都是服务器和安卓是通用的，iOS 出问题。