使用SecKeyWrapper加密16字节的UTF8（ccStatus == -4304）

Question

我正在使用Apple文档中CryptoExercise示例代码中的Apple SecKeyWrapper类来使用AES128进行对称加密。出于某种原因，当我加密1-15个字符或17个字符时，它会正确加密和解​​密。有16个字符，我可以加密，但在解密后，它会在CCCryptorFinal调用ccStatus == -4304之后抛出异常，这表示解码错误。 （去图。）

据我所知，AES128每个加密块使用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;
  }
}

......是我的问题的罪魁祸首。要解决它，我只需要评论它们。

据我所知，加密过程并非在加密方面进行填充，但当时仍然期望解密端的填充，导致解密过程失败（这通常是我遇到的情况）。

到目前为止，始终使用kCCOptionPKCS7Padding进行加密/解密对于满足length % 16 == 0的字符串和不满足SecKeyWrapper的字符串。而且，这是对CryptoExercise 示例代码的CommonCrypto类的修改。不确定这会如何影响您使用{{1}}与home-rolled包装器的那些。

Answer 2

我也使用CommonCrypto类遇到此问题，但是对于长度为16的倍数的任何字符串。

我的解决方案完全是黑客，因为我还没有找到问题的真正解决方案。

如果它是16的倍数，我在末尾用空格填充我的字符串。它适用于我的特定场景，因为数据上的额外空间不会影响另一方的数据接收，但我怀疑它适用于任何其他人的情况。

希望更聪明的人能指出我们正确的解决方案。