任何人在iOS 5加密方面遇到问题？ [英] Anyone else having trouble with iOS 5 encryption?
问题描述
有一个（相当复杂）的应用程序在iOS 4上正常工作，但在解决问题的iOS 5上失败。它正在解密一个SQLite数据库页面，最后16个字节似乎没有正确解密。
这是否与任何人一起响起？
更新
我确定，当CCCryptorUpdate的缓冲区长度为1008（1024 - 16）时，它只解密992字节如dataOutMoved参数中报告）。如果CCCryptorFinal返回剩余的字节，但是它报告零字节被移动，这将是可行的。但是，CCCryptorFinal正在报告一个-4304返回码（这是一个无用的kCCDecodeError）。
更新2
我已经把它作为一个出来的错误。我比较了字节字节从加密和输入到解密的输出，并比较了密钥。相同。但是如果缓冲区长度为1008，则解密总是失败，即使解密器被给予较大的输出缓冲区（在这种情况下，它需要1024）。我认为它可以正常工作1024，虽然我没有超过第一个奇怪的大小的缓冲区来告诉。
Etc
$ b $嗯，看来没有什么解密。这是使用一体化CCCrypt（）接口，消除了CCCryptorCreate / Update / Final的排序错误的机会。我想知道AES128是否存在问题？
一个好奇的事情是，当DB的第1页被加密时，加密总是返回比我所说的更多的16个字节它 - 如果我告诉它1008它报告1024，如果我告诉它1024它报告1040.没有其他页面，我没有看到CCCrypt如何知道它正在处理的页面。就像我说的，好奇。
发现它（我想）
旧代码指定 kCCOptionPKCS7Padding ，据我所知，它应该仅用于加密缓冲区长度不是块长度的倍数（以及提供额外的输出缓冲区空间）的位置。这导致几乎所有的解密操作都失败了-4304。但是在iOS 4中，这些操作仍然会移动他们已经解密的数据（这基本上是所有的），而iOS 5发生了变化，如果操作失败，所有数据移动被抑制（最后一个块几乎总是会失败）。 / p>
关闭填充选项可使代码生效，而不发布任何错误。
如上所述，如果有错误，则从iOS 4到iOS 5的更改将不再复制到目标缓冲区。所以在iOS 4中，可能会忽略错误，但仍然会获得良好的效果，而在iOS 5中却无效。（我没有写出原始代码 - 我从不会忽略错误。）
错误是由于在执行固定长度的块多重操作时指定了 kCCOptionPKCS7Padding 。 （不完全确定在填充时如何安排缓冲区，但这不是我需要做的。）删除该选项会导致操作无错误。
Have a (rather complex) app that works fine on iOS 4 but fails on iOS 5 with a decryption problem. It's decrypting a SQLite DB page, and the last 16 bytes do not appear to be properly decrypted.
Does this ring a bell with anyone?
Update
I've determined that, when CCCryptorUpdate is given a buffer length of 1008 (1024 - 16) it only decrypts 992 bytes (as reported in the dataOutMoved parameter). This would be OK if CCCryptorFinal returned the remaining bytes, but it reports zero bytes moved. However, CCCryptorFinal is reporting a -4304 return code (which is an unhelpful kCCDecodeError).
Update 2
I've pretty nailed it as an out-and-out bug. I've compared byte-for-byte the output from encryption and the input to decryption, and compared the keys. Identical. But if buffer length is 1008 then decryption always fails, even when the decryptor is given a larger output buffer (it says it needs 1024 in that case). I assume it works fine for 1024, though I haven't gotten past the first oddball sized buffer to tell.
Etc
Well, it appears that nothing decrypts. This is using the "all in one" CCCrypt() interface that removes any chance of an error with the sequencing of CCCryptorCreate/Update/Final. I wonder if it's a problem with AES128?
A curious thing is that when page 1 of the DB is encrypted the encryption always reports back 16 bytes more moved than what I tell it -- if I tell it 1008 it reports 1024, if I tell it 1024 it reports 1040. No other page does that, and I don't see how the CCCrypt could know what page it's processing. Like I said, curious.
Found it (I think)
The old code was specifying kCCOptionPKCS7Padding, which, as I understand it, should only be used for encrypting where the buffer length is not a multiple of the block length (and where additional output buffer space is provided). This caused virtually all decrypt operations to fail with -4304. But in iOS 4 the operations would still move the data they had decrypted (which was essentially all of it), while iOS 5 changed such that all data movement was suppressed if the operation failed (and the last block would almost always fail).
Turning off the padding option makes the code work without posting any errors.
As described above, there was a change from iOS 4 to iOS 5 in that data is no longer copied to the target buffer if there is an error. So in iOS 4 one could be ignoring errors and still get good results, while that doesn't work in iOS 5. (I didn't write the original code -- I never would have ignored the errors.)
The errors were due to having kCCOptionPKCS7Padding specified while doing fixed-length block-multiple operations. (Not entirely sure how one arranges the buffers when doing padding, but it's not something I need to do.) Removing that option causes the operations to be error-free.
这篇关于任何人在iOS 5加密方面遇到问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
