There are several public-domain implementations of AES. I chose apublic domain implementation of AES by Philip J. Erdelsky to use as the basis some Objective-C categories that make encrypting and decrypting files and data using AES-256 easy.

The first category is onNSFileManager,and allows you toencrypt a file in the filesystem. It takes a file at a particular pathname,encrypts it using a passphrase,and then writes the encrypted contents to a new specified file location. This version has relatively low memory overhead,as it streams the data in chunks both for reading and writing,so only the chunk currently being encrypted is in memory. The category adds two methods toNSFileManager,one for encrypting,the other for decrypting. These methods are the best choice when your source data already exists in the file system,especially on the iPhone,because of how little memory it uses to do the work. Here is an example of using the category onNSFileManager toencrypt a file:

 NSError *error = nil ;
 if (![ [ NSFileManager defaultManager  ]  AESEncryptFile:  @" /path/to/input file"  toFile:  @" /path/to/output file"  usingPassphrase:  @" My secret password"  error:  &error ]  )
 {
   NSLog (@" Failed to write encrypted file. Error = %@" ,[ [ error userInfo  ]  objectForKey:  AESEncryptionErrorDescriptionKey ]  );
 } 

There is also a category onNSData that will let youencrypt a chunk of data that’s already in memory. This version creates a newNSData object with the encrypted contents of the originalNSData instance. If your data is already in memory,and you want an encrypted or decrypted version of it,then theNSData methods are the way to go. Here is an example of using encrypting anNSData object with AES:

 NSData *encryptedData = [ data AESEncryptWithPassphrase:  @" My secret password"   ]  ;

Pretty easy,huh? Okay,now,this is a symmetric block cypher,it is not public-key encryption,so if you store your passphrase as a string in your application (as opposed to making the user enter it or storing it in the keychain) then you’re giving somebody the ability to decrypt your encrypted application data,so just be forewarned.

Also,I make no warranties about how secure this is. As far as I know,AES-256 has not been broken yet,however I cannot say for certaint that there are no weaknesses in the AES implementation I’ve used. I don’t see any obvIoUs problems but I am not a cryptographer. I haven’t heard of any weaknesses in this particular implementation,but any use of this is completely at your own risk.

Here is a zip file containing the two categories and the AES implementation . Just add these to your Xcode project,include the appropriate headers,andencrypt away.

Oh,and,one more important thing: If you use this in an iPhone application that you plan to sell on the App Store,it may lengthen the review process,as you will have to declare that you are using encryption,and will likely have to create and upload aCCATS form and wait for Apple to review it before your app will go up for sale. Read the iTunes Connect Developer Guide for more information on CCATS and the process before deciding to use this in an iPhone application for sale,please.

UPDATE: Jim Dovey author of the terrificOutput iPhone App ,posted a category onNSMutableData in the comments to this post that uses the crypto libraries already available on the Mac and iPhone to do AES-256 encryption. According to Jim,this means you don’t need a CCATS form because Apple’s exporting the encryption code,not you,so check it out Thanks,Jim.