我有一个非常复杂的应用程序，在iOS 4上运行良好，但在iOS 5上由于解密问题而失败。它正在解密SQLite DB页面，最后的16个字节似乎没有被正确解密。
这个问题有人遇到过吗？
更新
我确定，当CCCryptorUpdate给出长度为1008（1024-16）的缓冲区时，它只解密了992个字节（如dataOutMoved参数中所报告的）。如果CCCryptorFinal返回剩余的字节，则可以进行解密，但它报告移动的字节数为零。然而，CCCryptorFinal报告了一个-4304的返回代码（这是一个无用的kCCDecodeError）。
更新2
我几乎肯定是一个明显的错误。我逐字比较了加密输出和解密输入，并比较了密钥。完全相同。但是，如果缓冲区长度为1008，则即使在给解密器提供更大的输出缓冲区时（在这种情况下，它表示需要1024），解密也总是失败的。我假设它对于1024也很好，尽管我还没有通过第一个奇怪大小的缓冲区。
等等
嗯，好像什么都没有解密。这是使用“all in one” CCCrypt() 接口，消除了任何CCCryptorCreate/Update/Final顺序错误的机会。我想知道这是否是AES128的问题？
有趣的是，当加密DB的第一页时，加密总是报告移动的字节数比我告诉它的多16个字节-如果我告诉它1008，它会报告1024，如果我告诉它1024，它会报告1040。没有其他页面这样做，我不知道CCCrypt如何知道它正在处理哪一页。就像我说的，很奇怪。
找到了（我想）
旧代码指定了kCCOptionPKCS7Padding，据我所知，这应该只用于在缓冲区长度不是块长度的倍数（并提供附加输出缓冲区空间）的情况下进行加密。这导致几乎所有解密操作都失败，并显示为-4304。但在iOS 4中，操作仍然会移动它们已经解密的数据（基本上是全部），而iOS 5更改为如果操作失败，则抑制所有数据移动（并且最后一个块几乎总是失败）。
关闭填充选项使代码可以正常工作，而不会发布任何错误。