Is it possible to use AES128 with GCM mode on iOS?

Question

So my question for you stackoverflow geniuses is: if there a way (native, library, framework, whatever..) to encrypt data with AES (preferably 128 but could be 256 too) using a strong Authenticated encryption algorithm, let's say GCM mode?

Question is short, I have done some research and I only found one library that seems to support it ( RNCryptor ) but it also seems to use password to crypt instead of keys (like you provide a password and the library made the key) and I don't like that a lot, I prefer to manage my keys myself.

I also look at CommonCryptor.h and I found that line, which seems to me the only reference of GCM in commoncryptor source code (but I could be wrong, actually I am probably wrong) :

case kCCModeGCM: if((ref->symMode[direction].gcm = getCipherMode(cipher, mode, direction).gcm) == NULL) return kCCUnimplemented;

Thanks by advance !

Answer 1

Thanks to owlstead suggest I take a look deeper into RNCryptor and found a solution.

First of all after lots of googling it's seems that Zaph were right and iOS doesn't provide GCM but use it in iOS. ref there: iOS Security feb 2014

Second, RNCryptor doesn't use GCM but use AES256 in CBC mode (Cipher Block Chaining), which is fine, and then authenticate with HMAC+SHA1. This fits my requirements.

To encrypt with a key and to skip the password derivation part, RNCryptor provide this function:

NSData *encryptedData = [RNEncryptor encryptData:yourData
                                        withSettings:kRNCryptorAES256Settings
                                       encryptionKey:encryptionKey
                                             HMACKey:HMACKey
                                               error:&error];

and then decrypt with this

NSData *decryptedData = [RNDecryptor decryptData:encryptedData withEncryptionKey:encryptionKey HMACKey:HMACKey error:&decryptionError];

RNCryptor also provide random generation methods for keys.

Note: take care when using AES256, the key schedule can be weak: Schneier article but no drama and there are other point of view on AES256 that are pros: Colin Percival article