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

Question

有一个(相当复杂)的应用程序在iOS 4上正常工作但在iOS 5上因解密问题而失败.它正在解密SQLite数据库页面,最后16个字节似乎没有被正确解密.

这对任何人都响了吗？

更新

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

更新2

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

等等

好吧,似乎没有解密.这是使用"多合一" CCCrypt()接口,消除了与CCCryptorCreate /更新/最后的测序错误的机会.我想知道这是AES128的问题吗？

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

发现它(我认为)

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

关闭填充选项可使代码工作而不会发布任何错误.

Answer 1

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

这些错误是由于kCCOptionPKCS7Padding在进行固定长度的块多次操作时指定的.(不完全确定在填充时如何排列缓冲区,但这不是我需要做的事情.)删除该选项会导致操作无错误.