2

I have seen this thread, and the encryption techniques mentioned there is working well. But not in all cases.

Requirement:

Simple, take one image, encrypt it, and store the encrypted data. Later, get the encrypted data, decrypt it, recreate the original image and show.

What I have done

From the above mentioned thread, I found NSData additions for AES 256 encryption. I tried to use it but with partial success. This is the code

//encryption
NSData *srcData       =   UIImageJPEGRepresentation(srcImage, 1.0);
NSLog(@"srcData length : %d",[srcData length]);
NSData *encryptedData =   [srcData AES256EncryptWithKey:KEY];
NSLog(@"encrypted data length : %d",[encryptedData length]);

........

//later..
//decryption
decryptedImage  =   [UIImage imageWithData:[encryptedData AES256DecryptWithKey:KEY]];
imageView.image =   decryptedImage;

What is happening

For a small image, say image with resolution 48*48, this code is working successfully. But when I run the code in an image with higher resolutions, say 256 * 256, the method AES256EncryptWithKey failing with error kCCBufferTooSmall (-4301).

Questions

  1. Does AES 256 impose any limit on the size (in bytes) of the payload to be encrypted?
  2. If the answer to first question is YES, then what kind of encryption algorithm to use in iphone, to encrypt image (probably big ones)?
  3. If the answer to the first question is NO, then why this error?
Community
  • 1
  • 1
Krishnabhadra
  • 34,169
  • 30
  • 118
  • 167

1 Answers1

1
  1. No, not really. Some hash functions do have a maximum, but that's more in the order of 2^64, so generally you don't have to worry.
  2. N/A
  3. It has probably something to do with the dataWithBytesNoCopy in combination with the malloc call, but it is hard to find out without actually running the code.

Note that that wrapper is pretty braindead, as it does require encrypting all at once, without using CCCryptorUpdate. It does not use an IV which jeopardizes security. It handles the keys as strings. Finally, it creates too big a buffer size for decryption. You are better off creating your own using a more reliable source.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263