
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。
1 ysc3839 2019-11-28 15:26:06 +08:00 用什么库解密的?报什么错?代码? |
2 xiangyuecn 2019-11-28 15:32:49 +08:00 .net 的,你那 ios 瞎几把写吧 |
3 U7Q5tLAex2FI0o0g 2019-11-28 15:33:58 +08:00 做过 iOS、Android、PHP 三端的相互加解密( AES/CBC/PKCS7Padding ),没有问题。 楼主贴代码吧( v2 回帖代码不好看,建议 gist ) |
4 xiangyuecn 2019-11-28 15:35:02 +08:00 ios 的那坨这么短,目测应该是没有填充 |
5 Gehrman OP Android 用的自带的库,报错是这个 BadPaddingException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT 现在关键的是 Android 的加密和解密和在线工具是一样的 |
6 Gehrman OP @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 那边怎么能做到解密,虽然这种情况很少,但是遇到了也是好奇 |
7 ZavierXu 2019-11-28 15:41:50 +08:00 不要怀疑算法……肯定是你自己写错了…… |
8 Gehrman OP @xiangyuecn 瞎写正常应该也解不出来吧,这种情况遇到两次了,第一次以为 Android 这边写错了,好奇 iOS 有什么奇怪的方法 |
9 mcluyu 2019-11-28 15:48:23 +08:00 iOS CommonCrypto 库里就只有 kCCOptionPKCS7Padding 和 kCCOptionECBMode,没有 PKCS5PADDING,如果 Android 和其他端能对应, 那应该是填充问题。 |
10 Gehrman OP @mluyu 跟 iOS 那边对了下,设置确实是 PKCS7Padding,但是这也解释不了 iOS 为什么能将 c 和 b 都解回 a。而且在线工具设置成 PKCS7Padding 结果跟主题也是一样的 |
11 codeisjobs 2019-11-28 16:07:10 +08:00 via iPhone 我正好做了这个。 |
12 codeisjobs 2019-11-28 16:09:28 +08:00 via iPhone 和你情况差不多,安卓单独加解密没问题,iOS 单独加解密也没问题,服务器单独也没问题,服务器到安卓也没问题。iOS 的到服务器就有问题,后来查出来是 iOS base 64 加密格式和通用的不太一样。需要换个参数,这个就得自己试试是哪个参数正确的了 |
13 U7Q5tLAex2FI0o0g 2019-11-28 16:13:58 +08:00 @Gehrman #6 Swift 的话我用的这个库: https://github.com/krzyzanowskim/CryptoSwift |
14 jenschen 2019-11-28 16:19:02 +08:00 via iPhone 做过 aes 和 rsa,三端都没有问题。一般现成的库应该不会有问题。仔细看看加密模式,长度是否相同。 |
15 Gehrman OP @codeisjobs 我是开发 Android 的,现在 95%的情况我们三端是 OK 的,剩下的就是主题中提到的 iOS 能解 b 这种”不规范“的密文, 只是不想到时候被测试 bb 为什么 iOS 可以 Android 不行才发的这个贴。 设备端老哥已经在看问题,不知道能不能避免生成 c 这种密文 |
18 codeisjobs 2019-11-28 16:27:53 +08:00 via iPhone @Gehrman 大概率是 iOS 的 bade64 加密参数用的默认的,导致生成后不规范。 |
19 codeisjobs 2019-11-28 16:31:01 +08:00 via iPhone @Gehrman 可能 iOS 还要做加密后,把密文里的\r\n 给去掉。。。坑爹 iOS 会做换行 |
20 Gehrman OP @codeisjobs 目前情况下 iOS 应该不需要修改,现在是 iOS 能解的 Android 不能解,Android 不能解的别的端也不能解,所以现在应该是设备端的锅吧 orz |
23 codeisjobs 2019-11-28 17:36:31 +08:00 via iPhone @Gehrman iOS 能解,安卓不能解?密文不是服务器下发的吗? |
24 42byte 2019-11-28 17:59:56 +08:00 @littleylv CryptoSwift 是作者自己用 Swift 重新实现了 AES 算法,走 CPU 计算的,没使用系统自带的 CommonCryptor 不能硬件加速,性能很差 |
| /td> | 25 U7Q5tLAex2FI0o0g 2019-11-28 18:22:54 +08:00 @42byte #24 谢谢科普 |
26 elvodn 2019-11-28 18:40:42 +08:00 这里 55 - 57 行 自动处理了未 PADDING 格式 https://github.com/krzyzanowskim/CryptoSwift/blob/master/Sources/CryptoSwift/PKCS/PKCS7Padding.swift#L55 |
27 Gehrman OP @codeisjobs 是服务器下发的, K/pPwvZh689ZW/ud2ykbKQ== K/pPwvZh689ZW/ud2ykbKYcWNWCyI1ScsFzvlZb8qs8= 这两段密文 iOS 用同样的 key 和 iv 都解成了 15068#1574908387 这就是我疑惑的点 |
28 codeisjobs 2019-11-29 09:07:54 +08:00 via iPhone @Gehrman 如果是服务器下发的密文,安卓解不了,那可能是安卓的代码有问题。一般都是服务器和安卓是通用的,iOS 出问题。 |