我正在使用 CryptoExercise 中的 Apple 的 SecKeyWrapper 类Apple 文档中的示例代码使用 AES128 进行一些对称加密。出于某种原因，当我加密 1-15 个字符或 17 个字符时，它会正确地加密和解密。对于 16 个字符，我可以加密，但在使用 ccStatus == -4304 调用 CCCryptorFinal 后，它会在解密时引发异常，这表明解码错误。 (去图。)
我知道 AES128 每个加密 block 使用 16 个字节，所以我的印象是错误与落在 block 边界上的明文长度有关。有没有人在使用 CommonCryptor 或 SecKeyWrapper 时遇到过这个问题？
最佳答案
下面几行...
// 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;
}
}
...是我的问题的罪魁祸首。要解决它，我只需将它们注释掉即可。
据我所知，加密过程不是在加密端进行填充，而是在解密端仍期望进行填充，从而导致解密过程失败(这通常是我遇到的情况)。
对于满足 length % 16 == 0 和不满足的字符串，始终使用 kCCOptionPKCS7Padding 加密/解密对我来说很有效。同样，这是对 CryptoExercise example 代码的 SecKeyWrapper 类的修改。不确定这对那些使用带有自制包装器的 CommonCrypto 的人有何影响。
关于iphone - 使用 SecKeyWrapper 中断加密 16 个字节的 UTF8 (ccStatus == -4304)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5884119/