其他人在使用iOS 5加密时遇到问题？

Question

有一个（相当复杂的）应用程序在iOS 4上运行良好但在iOS 5上因解密问题而失败。它正在解密SQLite数据库页面，最后16个字节似乎没有被正确解密。

这对任何人都响了吗？

更新

我已经确定，当CCCryptorUpdate的缓冲区长度为1008（1024 - 16）时，它只会解密992个字节（如dataOutMoved参数中所报告的那样）。如果CCCryptorFinal返回剩余的字节，这将是正常的，但它报告移动了零字节。但是，CCCryptorFinal报告了一个-4304返回代码（这是一个无用的kCCDecodeError）。

更新2

我把它当作一个彻头彻尾的错误。我比较了逐字节加密输出和输入到解密，并比较了密钥。相同。但是如果缓冲区长度是1008，那么解密总是会失败，即使解密器被赋予了更大的输出缓冲区（在这种情况下它说它需要1024）。我认为它适用于1024，但我还没有超过第一个奇怪的大小缓冲区来判断。

等

好吧，似乎没有解密。这是使用“all in one”CCCrypt（）接口，它可以消除CCCryptorCreate / Update / Final排序错误的可能性。我想知道这是AES128的问题吗？

奇怪的是，当数据库的第1页被加密时，加密总是报告比我告诉的更多移动16个字节 - 如果我告诉它1008它报告1024，如果我告诉它1024报告1040。没有其他页面这样做，我也看不到CCCrypt如何知道它正在处理哪个页面。就像我说的那样好奇。

找到它（我认为）

旧代码指定kCCOptionPKCS7Padding，据我所知，它只应用于加密缓冲区长度不是块长度的倍数（以及提供额外输出缓冲区空间的位置）。这导致几乎所有解密操作都以-4304失败。但是在iOS 4中，操作仍然会移动他们已经解密的数据（基本上是所有这些），而iOS 5改变了，如果操作失败（并且最后一个块几乎总是失败），所有数据移动都被抑制。 / p>

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

Answer 1

如上所述，从iOS 4到iOS 5的变化是，如果出现错误，数据不再复制到目标缓冲区。所以在iOS 4中，人们可能会忽略错误并且仍然可以获得良好的结果，而这在iOS 5中不起作用。（我没有编写原始代码 - 我永远不会忽略错误。）

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

Answer 2

在kCCOptionPKCS7Padding上删除kCCDecrypt时，如果kCCEncrypt之前的原始数据不是块长度的倍数，则kCCDecrypt之后的输出数据长度不同于kCCEncrypt之前的原始数据。

所以没有错误，但结果是错误的。