ios - 还有其他人遇到 iOS 5 加密问题吗？

Question

有一个(相当复杂的)应用程序在 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 几乎总是失败)，所有数据移动都会被抑制。

关闭填充选项可使代码正常运行而不会出现任何错误。

Answer 1

如上所述，从 iOS 4 到 iOS 5 发生了变化，如果出现错误，数据不再复制到目标缓冲区。因此，在 iOS 4 中，可以忽略错误并仍然获得良好的结果，而在 iOS 5 中则行不通。(我没有编写原始代码——我永远不会忽略错误。)

错误是由于在执行固定长度的 block 多操作时指定了 kCCOptionPKCS7Padding。 (不完全确定在进行填充时如何安排缓冲区，但这不是我需要做的事情。)删除该选项会导致操作没有错误。