以下几行......

The following lines...

// 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;
  }
}

...是我的问题的罪魁祸首。为了解决这个问题，我只需要对它们进行评论。

... are the culprits of my issue. To solve it, I simply had to comment them out.

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

As far as I can tell, the encryption process was not padding on the encryption side, but was then still expecting padding on the decryption side, causing the decryption process to fail (which is generally what I was experiencing).

始终使用 kCCOptionPKCS7Padding $ c到目前为止，加密/解密的$ c>对于满足长度％16 == 0 的字符串以及那些不满足的字符串。而且，这是对 CryptoExercise 示例代码的 SecKeyWrapper 类的修改。不确定这会如何影响您使用 CommonCrypto 与自制卷包装器。

Always using kCCOptionPKCS7Padding to encrypt/decrypt is working for me so far, for strings that satisfy length % 16 == 0 and those that don't. And, again, this is a modification to the SecKeyWrapper class of the CryptoExercise example code. Not sure how this impacts those of you using CommonCrypto with home-rolled wrappers.