我有一个非常复杂的应用程序,在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更改为如果操作失败,则抑制所有数据移动(并且最后一个块几乎总是失败)。
关闭填充选项使代码可以正常工作,而不会发布任何错误。