Geek asks and answers

Encryption of 16 UTF8 bytes with SecKeyWrapper breaks (ccStatus == -4304)

I am using the Apple class SecKeyWrapperfrom CryptoExercise sample code in Apple docs to perform symmetric encryption using AES128. For some reason, when I encrypt 1-15 characters or 17 characters, it encrypts and decrypts correctly. With 16 characters, I can encrypt, but when decrypting, it throws an exception after calling CCCryptorFinalc ccStatus == -4304, which indicates a decoding error. (Go number.)

I understand that AES128 uses 16 bytes per encrypted block, so I get the impression that the error has something to do with the length of the plaintext falling on the border of the block. Has anyone encountered this problem using CommonCryptoror SecKeyWrapper?

+3
source share
2 answers

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 problem. To solve this problem, I just had to comment on them.

As far as I can tell, the encryption process was not a complement on the encryption side, but then still expected to populate on the decryption side, as a result of which the decryption process failed (which, as a rule, I experienced).

Always use kCCOptionPKCS7Paddingfor encryption / decryption works for me so far, for strings that satisfy length % 16 == 0and those that do not. And, again, this is a modification of the SecKeyWrappersample code class CryptoExercise. Not sure how this will affect you with the help of CommonCryptowrapping machines.

+4
source

, CommonCrypto, , 16.

- , .

, 16. , , .

, - .

0

More articles:


All Articles