使用SecKeyWrapperencryption16个字节的UTF8（ccStatus == -4304）

我使用Apple文档中的CryptoExercise示例代码中的Apple SecKeyWrapper类与AES128进行一些对称encryption。 出于某种原因，当我encryption1-15个字符或17个字符时，它会正确encryption和解​​密。 有16个字符，我可以encryption，但在解密时，会在CCCryptorFinal调用ccStatus == -4304之后引发exception，这表示解码错误。 （去搞清楚。）

据我所知，AES128使用每个encryption块16个字节，所以我得到这样的印象，即错误与明文长度落在块边界上有关。 有没有人遇到这个问题使用CommonCryptor或SecKeyWrapper ？

Answer 1

以下几行…

 // We don't want to toss padding on if we don't need to if (*pkcs7 != kCCOptionECBMode) { if ((plainTextBufferSize % kChosenCipherBlockSize) == 0) { *pkcs7 = 0x0000; } else { *pkcs7 = kCCOptionPKCS7Padding; } } 

…是我的问题的罪魁祸首。 为了解决这个问题，我只好把它们评论出来。

据我所知，encryption过程不是在encryption方面的填充，但仍然期待在解密方面的填充，导致解密过程失败（这通常是我所经历的）。

对于我来说，总是使用kCCOptionPKCS7Padding进行encryption/解密，对于我来说，对于满足length % 16 == 0string和那些不是。 而且，这又是对CryptoExercise 示例代码的SecKeyWrapper类的修改。 不知道这是如何影响你使用CommonCrypto与家庭卷的包装。

Answer 2

我也使用CommonCrypto类遇到过这个问题，但是对于长度为16的倍数的任何string。

我的解决scheme是彻底的黑客，因为我还没有find真正的解决scheme。

我填充我的string的末尾有一个空格，如果它是16的倍数。它适用于我的特殊情况，因为数据上的额外空间不会影响另一方的数据接收，但我怀疑它会工作其他人的情况。

希望有人更聪明，可以指出我们正确的方向，以真正的解决scheme。