有一个(相当复杂的)应用程序在 iOS 4 上运行良好,但在 iOS 5 上运行失败并出现解密问题。它正在解密一个 SQLite 数据库页面,最后 16 个字节似乎没有被正确解密。
这会引起任何人的注意吗?
更新
我已经确定,当 CCCryptorUpdate 的缓冲区长度为 1008 (1024 - 16) 时,它只会解密 992 个字节(如 dataOutMoved 参数中所报告)。如果 CCCryptorFinal 返回剩余的字节,这将是可以的,但它报告移动了零字节。然而,CCCryptorFinal 报告了一个 -4304 返回码(这是一个无用的 kCCDecodeError)。
更新2
我已经把它确定为一个彻头彻尾的错误。我逐字节地比较了加密的输出和解密的输入,并比较了 key 。完全相同的。但是,如果缓冲区长度为 1008,那么解密总是会失败,即使解密器被赋予了更大的输出缓冲区(它表示在这种情况下它需要 1024)。我假设它适用于 1024,尽管我还没有通过第一个奇怪大小的缓冲区来判断。
等等
好吧,看来没有什么可以解密的。这是使用“一体式”CCCrypt() 接口(interface),该接口(interface)消除了 CCCryptorCreate/Update/Final 顺序出错的任何可能性。请问是不是AES128的问题?
奇怪的是,当 DB 的第 1 页被加密时,加密总是报告比我告诉它的多 16 个字节——如果我告诉它 1008,它报告 1024,如果我告诉它 1024,它报告 1040。没有其他页面这样做,而且我不明白 CCCrypt 如何知道它正在处理哪个页面。就像我说的,好奇。
找到了(我想)
旧代码指定了kCCOptionPKCS7Padding
,据我所知,它应该只用于加密缓冲区长度不是 block 长度的倍数(以及额外的输出缓冲区空间是假如)。这导致几乎所有解密操作都以 -4304 失败。但是在 iOS 4 中,操作仍然会移动他们解密的数据(基本上是所有数据),而 iOS 5 发生了变化,如果操作失败(最后一个 block 几乎总是失败),所有数据移动都会被抑制。
关闭填充选项可使代码正常运行而不会出现任何错误。
最佳答案
如上所述,从 iOS 4 到 iOS 5 发生了变化,如果出现错误,数据不再复制到目标缓冲区。因此,在 iOS 4 中,可以忽略错误并仍然获得良好的结果,而在 iOS 5 中则行不通。(我没有编写原始代码——我永远不会忽略错误。)
错误是由于在执行固定长度的 block 多操作时指定了 kCCOptionPKCS7Padding
。 (不完全确定在进行填充时如何安排缓冲区,但这不是我需要做的事情。)删除该选项会导致操作没有错误。
关于ios - 还有其他人遇到 iOS 5 加密问题吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8175947/