这是一个创建于 1857 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 条附言 · 2019-11-29 09:00:09 +08:00
K/pPwvZh689ZW/ud2ykbKQ==
K/pPwvZh689ZW/ud2ykbKYcWNWCyI1ScsFzvlZb8qs8=
这两段密文 iOS 用同样的 key 和 iv 都解成了 15068#1574908387
而 Android 和在线工具及前面朋友的验证都只能解第二段密文
K/pPwvZh689ZW/ud2ykbKYcWNWCyI1ScsFzvlZb8qs8=
这两段密文 iOS 用同样的 key 和 iv 都解成了 15068#1574908387
而 Android 和在线工具及前面朋友的验证都只能解第二段密文
 |
1
ysc3839 2019-11-28 15:26:06 +08:00
用什么库解密的？报什么错？代码？
|
 |
2
xiangyuecn 2019-11-28 15:32:49 +08:00
 .net 的，你那 ios 瞎几把写吧 |
 |
3
littleylv 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 @mcluyu 跟 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
littleylv 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  1
@littleylv CryptoSwift 是作者自己用 Swift 重新实现了 AES 算法，走 CPU 计算的，没使用系统自带的 CommonCryptor 不能硬件加速，性能很差
|
 |
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 出问题。
|
Select Language